Closed Bug 161846 Opened 20 years ago Closed 20 years ago
Let chrome keep it's domwin listeners for the lifetime of the window
SetNewDocument keeps calling RemoveAllListeners, which makes it difficult for chrome to attach listeners at all. We should be able to be a web progress listener, and always reattach our listeners for each new page. However, SetNewDocument will sometimes get called after the last web progress listener notification, so is not possibly to reliably listen to events on a window. AFAICT, SetNewDocument should only remove listeners that were attached to the current window from script. Chrome listeners on the dom window should be able to stay active for the life time of the window.
This blocks 30088 - type ahead find. It's creating a bug where type ahead find intermittently doesn't get attached to a new window.
This does not make sense to me. You can add listeners to the XUL <browser> element that will then persist (and not have to change the window's behavior of flushing event listeners).
Dave, do you have a way that I can use the <browser> element in an embedded app? I don't think there's currently away. My solution works in both cases. Why do chrome listeners need to automaticaly be removed from a window. What is could go wrong with changing that behavior?
Too big of a change at this stage, even if it did make sense.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.