[
https://issues.apache.org/jira/browse/TAP5-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046967#comment-13046967
]
Raul Montes commented on TAP5-1115:
-----------------------------------
Exactly, that was my suggestion in the issue mentioned
(https://issues.apache.org/jira/browse/TAP5-957?focusedCommentId=12969893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12969893)
but as you said, this is not pretty… (target attribute doesn't even validates
as XHTML 1.0…).
Please, if a Tapestry developer could comment on this ignored issue (besides
Bob's comment :) ), at least to know their opinion. If the proposed unload
event (instead of beforeUnload) is correct, the the fix is really simple, but
if not, then I could help to think on another solution.
> Tapestry.windowUnloaded should be set to true when the page is really unloaded
> ------------------------------------------------------------------------------
>
> Key: TAP5-1115
> URL: https://issues.apache.org/jira/browse/TAP5-1115
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Raul Montes
>
> Tapestry.windowUnloaded is setted to true on the beforeUnload event. But this
> event is not triggered only when the page is going to be unloaded. For
> example, when a user clicks a link to go to another page, both the
> beforeUnload and unload events are triggered. But, when a user clicks a link
> to download a file with Content-disposition set to attachment (or when the
> file cannot be opened inside the browser), the current page is _not_
> unloaded. In fact, although the beforeUnload event is triggered (because of
> the GET request sent), the unload event is never triggered, so the page stays
> right there. In this situations, any Ajax link stop working because its
> response is not proccessed anymore.
> I think the correct behaviour should be to set Tapestry.windowUnloaded on the
> unload event (triggered when the objects actually are going to be unloaded),
> or not setting it at all, because the behaviour using the beforeUnload is
> really a bad thing.
> https://issues.apache.org/jira/browse/TAP5-957 is somehow related to this
> issue, but this happens in many browsers, not just IE and when downloading
> files, which is critical (unlike javascript execution for which you can
> observe events...).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira