Opened 12 years ago
Closed 12 years ago
#8526 closed enhancement (fixed)
the default registration of on*unload handlers breaks fastback caches
Reported by: | alex | Owned by: | alex |
---|---|---|---|
Priority: | high | Milestone: | 1.3 |
Component: | Core | Version: | 1.2.3 |
Keywords: | onunload, cache, fastback, addOnUnload | Cc: | James Burke, phiggins, wildbill, bill |
Blocked By: | Blocking: |
Description
On browsers that support "fast-back" (Safari, Firefox, etc.), Dojo's registration of a default handler on the beforeunload
and unload
events totally destorys the ability of dojo-using pages to be considered for this caching scheme, slowing down these pages for many users.
The proposed solution, as discussed with jburke and phiggins, is to only add the handler to the window object upon the first call to addOnUnload
or addOnBeforeunload
. This may affect behavior on pages which employ this pattern today:
dojo.connect(dojo, "unloaded", function(){ ... });
but which do not at any point call:
dojo.addOnUnload(...);
For these pages, the unloaded call will not happen since the window-level registration will not occur. Several strategies for handling this can be imagined, but none of them prevent the basic issue that some listeners to dojo.unloaded may not be called.
This is mitigated by noting that:
- no dojo code actually does this
- we will document the change in behavior
- that no browser for which fast-back caching is available also requires any default cleanup
Closing this bug requires:
- updating the release notes for 1.3: http://dojotoolkit.org/book/1-3-release-notes
- ensuring that the documentation for
dojo.unloaded
is updated - ensuring that docs are in place for
dojo.addOnLoad()
Change History (7)
comment:1 Changed 12 years ago by
Status: | new → assigned |
---|
comment:2 Changed 12 years ago by
comment:3 Changed 12 years ago by
(In [16500]) change the behavior of addOnUnload and addOnWindowUnload to prevent default registration of unload and onbeforeunload handlers since they can defeat fastback behavior. Updating docs for affected APIs and adding a test of the system to verify that it works. The test is kind of a pain to run, but it does proove that the change has the intended behavior.
Refs #8526
comment:4 Changed 12 years ago by
Is it possible this would also impair or break back button support for these browsers? I am experiencing a problem with FF where the back.js:handleBackButton is never called. I also was unable to get the back button to work with Safari 3.1.2 + dojo 1.2.3
comment:6 Changed 12 years ago by
Matt: the dojo.back support does not work across pages, once the browser swaps out the document. If you see some errors with dojo.back support, it is best to file those as separate dojo.back bugs with test cases if possible.
Just explicitly noting: the same treatment applied dojo.addOnUnload should be applied to dojo.addOnWindowUnload too.