You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Massimo Lusetti (Closed) (JIRA)" <ji...@apache.org> on 2011/10/20 13:12:10 UTC
[jira] [Closed] (TAP5-1115) Tapestry.windowUnloaded should be set
to true when the page is really unloaded
[ 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