[
https://issues.apache.org/jira/browse/TAP5-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Massimo Lusetti closed TAP5-1115.
---------------------------------
Resolution: Won't Fix
Assignee: Massimo Lusetti
The current behavior of ajax request result processing test if the request is
blank over windowUnloaded so if the response is not blank is never lost.
I tested this on 5.3-beta-24
> 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
> Assignee: Massimo Lusetti
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
