Re: [D3E] Possible Changes to Mutation Events

On Jul 16, 2008, at 2:03 PM, Stewart Brodie wrote:

> 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?

It will only grow without bound if every mutation event handler in  
turn modifies the DOM itself, or if a compound DOM operation is  
unbounded.

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

No, the event is dispatched when it comes off the queue, therefore the  
listeners in effect at that time should be the ones that apply, same  
as for any other event.

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

It's certainly not simple (unless both WebKit and Gecko developers  
missed something). The memory needed for the queue will be 0 in most  
cases since the vast majority of pages register no mutation event  
listeners. Even if they do, the queue size is likely to be trivial in  
all the circumstances I can imagine and to be dwarfed by the size of  
the DOM itself.

Regards,
Maciej

Received on Wednesday, 16 July 2008 21:53:15 UTC