Re: [D3E] Possible Changes to Mutation Events

Maciej Stachowiak <> wrote:

> On Jul 16, 2008, at 2:03 PM, Stewart Brodie wrote:
> > Maciej Stachowiak <> 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.

Unbounded queueing is a real concern.  Having said that, the current
situation is that we have unbounded recursion, which is equally
unacceptable, although the recursion depth is at least defined by the number
of recursive calls made by the event listeners, whereas the queue length is
dependent on the number of nodes in the affected subtree, which is likely to
be substantially greater.

Maybe we just have to hope nobody's listening for the events at all so they
can be optimised away completely.

Stewart Brodie

Received on Thursday, 17 July 2008 00:00:01 UTC