427844 - Fire mutation events on nodes added by parser during page load

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, enhancement)

Description

[Weston Ruter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

In thinking about how best to implement a source code filter for the DOM, I thought about how useful it would be if there were a sort of SAX parser available to JavaScript that would enable the handling of DOM nodes as they are parsed; elements that should be discarded (such as ads) can be done so by returning NULL by the handler. In the same way, the node could be replaced by returning a new DOM node by the handler. 

My proposal: One way that such a SAX parser could be implemented is to extend mutation events to the DOM loading stage. As the document is loading, a new 'DOMNodeInserted' mutation event could fire on each new DOM node created by the parser. An event would fire after the node and all of its children are created, thus it could be used to emulate DOMContentLoaded by watching for when the "body" element is inserted.

Note that DOM 2 states that presently mutation events are not cancelable, so a handler would have to remove the node in question manually.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jesse Ruderman]

Gecko did this a long time ago, but it was removed for speed and sanity reasons (see bug 90983).

Comment 2

[Weston Ruter]

What if this functionality is enabled if only a mutation event listener has been added? That would maintain the performance in the general case where mutation events aren't used or only assigned upon DOMContentLoaded, but if a listener were added before DOMContentLoaded, then performance would be decreased in order to provide this additional functionality.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Event listeners are quite often added before DOMContentLoaded.
And we would have to change content sink to notify always if there was
mutation listeners. I guess that would slow down page load pretty
dramatically.

IMO, a real DOM filter shouldn't be based on DOM mutation events, but something
simpler and faster (something not available in browsers currently, AFAIK).

Comment 4

[Weston Ruter]

@Smaug: What I mean is that mutation events are not yet commonly used (AFAIK), so the vast majority of websites would not start exhibiting decreased performance. And if it were publicized that listening for mutation events before page load made a hit on performance, developers would be advised to hold off adding such listeners until DOMContentLoaded.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Saying "it doesn't matter that this feature is slow, no-one uses it anyway so it won't affect anyone" is a pretty poor argument for including a feature :)

We shouldn't include features that slow things down to the point where you really don't want to use the feature. It was IMHO a mistake to add mutation even support in the first place. They are a royal pain to implement, useless in the face of more advanced mutations, and a performance hog when used.

Note that we do already have use the trick to only enable the events when used. But even just checking for if the events are used is costing us measurable performance.