Closed Bug 161846 Opened 20 years ago Closed 20 years ago

Let chrome keep it's domwin listeners for the lifetime of the window

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: aaronlev, Assigned: aaronlev)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Blocks: isearch
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
QA Contact: rakeshmishra → trix
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.