- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 16 Jul 2008 17:53:39 -0700
- To: Stewart Brodie <stewart.brodie@antplc.com>
- Cc: Laurens Holst <lholst@students.cs.uu.nl>, Doug Schepers <schepers@w3.org>, public-webapps@w3.org
On Jul 16, 2008, at 5:00 PM, Stewart Brodie wrote: > Maciej Stachowiak <mjs@apple.com> wrote: > >> >> 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. > > 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. Can you describe a plausible scenario where growth of the mutation event queue would be a significant issue? You've said repeatedly you are worried about it but have not given an example of when this might happen. Are you talking about the kind of programmer error that results in an infinite loop? > Maybe we just have to hope nobody's listening for the events at all > so they > can be optimised away completely. That's certainly the common case.
Received on Thursday, 17 July 2008 00:54:19 UTC