Re: [D3E] Possible Changes to Mutation Events

Maciej Stachowiak <mjs@apple.com> wrote:

> The purpose is not optimization, but rather reducing code complexity  
> and risk. DOM mutation events can make arbitrary changes to the DOM,  
> including ones that may invalidate the rest of the operation. Let's  
> say you call parent.replaceChild(old, new). If the DOMNodeRemoved  
> notification is fired before the removal of old, or even between the  
> removal and the insertion, it might remove old from parent and moved  
> elsewhere in the document. The remove notification for new (if it  
> already had a parent) could also move old, or new, or parent. There's  
> no particularly valid reason to do this, but Web-facing  
> implementations must be robust in the face of broken or malicious  
> code. This means that at every stage of a multistep operation, the  
> implementation has to recheck its assumptions. In WebKit and Gecko,  
> the code for many of the basic DOM operations often is more than 50%  
> code to dispatch mutation events, re-check assumptions and abort if  
> needed. Dispatching mutation events at the end of a compound operation  
> doesn't have this problem - there is no need to re-check assumptions  
> because the operation is complete.

I agree with all that, but it's not the whole story, because making this
change has potentially severe consequences for memory usage if you start
moving large subtrees around within a document.  Just how long is the event
queue allowed to get?

If you're going to postpone the event dispatch, when do you build the
listener list for each event?  Presumably you must built it at the time at
which you queue the event?  If so, then that's a whole lot more work that's
now necessary in removeEventListener[NS].


> > It seems to me that such a definition would possibly make  
> > implementations more complex if not impossible (in case the  
> > implementation provides no access to events-less methods), and put  
> > more constraints on the underlying implementation, as the  
> > implementation would now be required to throw the events separately  
> > from the actual operations (which I do not think would be good  
> > design).
> 
> No, it would make implementations much simpler by removing all the  
> code that handles the very unlikely case of the mutation event  
> listener modifying the DOM in a way that invalidates the operation. I  
> know for sure this is the case for WebKit's DOM implementation, and  
> Mozilla folks have told me the same is true for Gecko.

It complicates our implementation too, but at least it's relatively bounded
and simple to revalidate compared to the unbounded memory usage of queueing
everything up.


-- 
Stewart Brodie

Received on Wednesday, 16 July 2008 21:03:01 UTC