568658 - storage and removal of DOM Mutation event listener functions

Status: RESOLVED WONTFIX

(DevTools :: General, defect)

Description

[David Dahl :ddahl]

keep track of all DOM Mutation event listener functions so they are easily removed when DOM Mutations are toggled off.

Comment 1

[Mihai Sucan [:msucan]]

Attachment: patch 1

Hello David!

This is the proposed patch. This applies cleanly on your repository.

The attachment of DOM mutation event listeners was handled by the 
ConsoleDOMListeners object, for each attachment. Callback functions were created 
for every event, and stored for every HUD.

My proposal is to have only one event handler, for all HUDs, for all events.  
Thus we reduce memory usage a lot, and we simplify the code.

Besides that work I also did the following related fixes:

- The HUDService.windowInitializer() method creates instances of the 
HeadsUpDisplay object.

When the HUD is constructed with config.consoleOnly = false, it also attaches 
the new HUDConsole instance to the contentWindow. Essentially this exposes the 
window.console API. The HUD code also attached 

When the HUD is constructed with config.consoleOnly = true, the above does not 
happen. However, the windowInitializer() method included a copy of the code 
which does that - albeit with a bug, it did reference this.hudId, instead of 
hudId.

I changed the code such that only the windowInitializer() exposes the 
window.console API, and attaches the mutation listeners. The HeadsUpDisplay no 
longer does this, irrespective of the consoleOnly value.

- DOM Mutation events were repeated several times. Now they are reported only 
once, as needed.

- Users couldn't disable the DOM mutation event listeners once they enabled 
them.

- The test code did not properly run the network test - the testNet() function.  
Changed the code such that testNet() runs correctly now.

The initial code for testNet() changed the content.location and immediately 
tried to check the result (with executeSoon()). The page loading operation 
is async, so an event listener was needed.

- The testDOMMutation() function did not correctly either, so I made the 
same changes. However, the test still fails, because for some reason the 
window.console API is not available, so the mutation events handler fails 
silently. I did debug the code to determine that the 
HUDService.mutationEventsHandler() method does not find the window.console 
object. Any ideas why? It works when I run Firefox normally.


I know this patch is low priority. I submitted it, for future reference, 
and for the testNet() fix - as we discussed on IRC.

Thanks!

Comment 2

[Kevin Dangoor]

Pinging this bug because it has a patch, but there is no feedback requested...

Comment 3

[David Dahl :ddahl]

We killed the DOM Mutation events - for now. We will revisit this in a later release as well as other fun events.

Comment 4

[Dave Camp (:dcamp)]

Yeah, this is no longer relevant.  We'll open new bugs when we get the new mutation observers.