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

Status: RESOLVED WONTFIX

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

Description

[Aaron Leventhal]

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.

Comment 1

[Aaron Leventhal]

This blocks 30088 - type ahead find. It's creating a bug where type ahead find
intermittently doesn't get attached to a new window.

Comment 2

[Aaron Leventhal]

Attachment: Removes only script listeners to window in SetNewDocument(). Removes all the listeners when the window is destroyed.

Comment 3

[Aaron Leventhal]

Attachment: Removes unnecessary |mListenerManager = nsnull| code in destructor, which happens automatically anyway

Comment 4

[David Hyatt]

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).

Comment 5

[Aaron Leventhal]

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?

Comment 6

[Aaron Leventhal]

Too big of a change at this stage, even if it did make sense.