Open
Bug 305935
Opened 19 years ago
Updated 2 years ago
allow Web authors to "say" that onunload, etc. handlers are fastback-safe
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
NEW
People
(Reporter: dbaron, Unassigned)
References
Details
(Keywords: perf)
One of the things that we check for before saving a presentation (in particular, nsDocument::CanSavePresentation calls nsEventListenerManager::HasUnloadListeners) is that the page doesn't have any onunload or onbeforeunload listeners. This could provide a very frustrating experience for Web developers who: * need to use onunload or onbeforeunload for some reason, and * care about the performance of their pages in Gecko, since they would be unable to make their pages get the benefits of fastback. We should care about helping Web developers who care about Gecko, and we certainly don't want to make them mad at us. This is a little risky, though, since it introduces a situation that authors aren't likely to test very well, so I have some mixed feelings about whether we should do it at all. One possible mechanism for doing this is to consider the presence of onpagehide and/or onpageshow handlers to be a statement from the author that the onunload/onbeforeunload handlers don't make the page unusable. However, we should make sure that such handlers coming from extensions/chrome don't cause this change (at the very least by ensuring that there's a way for extensions/chrome to add listeners that doesn't affect this test). (I thought we were also checking for onsubmit, but we don't seem to be.)
Reporter | ||
Updated•19 years ago
|
Summary: allow Web authors to "say" that onunload, etc. handlers are fastback-safe (idempotent, etc.) → allow Web authors to "say" that onunload, etc. handlers are fastback-safe
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•