- From: David Flanagan <dflanagan@mozilla.com>
- Date: Tue, 05 Jul 2011 12:00:52 -0700
- To: Olli@pettay.fi
- CC: Olli Pettay <Olli.Pettay@helsinki.fi>, Adam Klein <adamk@chromium.org>, Ojan Vafai <ojan@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 7/4/11 2:22 PM, Olli Pettay wrote: > Handling of insertedNodes/removedNodes becomes tricky if there are > several listeners and the first one of those adds or removes child > nodes. Should the listeners which will be called later get the same > insertedNodes/removedNodes as the first listener, or should the lists be > updated to reflect what has actually changed? Questions like these are why I agree with jjb and think that it is a no-brainer that DOM modifications should be forbidden in mutation listeners. Earlier in this thread, I proposed that the document tree should be put into read-only mode while mutation events are fired, and that any attempt to modify the tree from a mutation listener should throw NO_MODIFICATION_ALLOWED_ERR. The exception code and the notion of readonly nodes are already defined (but unused, as far as I know) in DOM Level 2 Core. I can't help pointing out one non-trivial benefit of forbidding mutations from mutation listeners: it makes it impossible for developers to create inifinitely recursive mutations. Boris wrote: >> By restricting mutation listeners to explicitly avoid DOM mutation, the >> most sophisticated case is no different than the simple case. Then all >> three can be accommodated. > > If such a restriction were feasible, it might be worth looking into. > It would involve not passing any DOM nodes to the mutation listener, I > suspect. I think this is worth looking into to figure out if it is feasible. Boris, you have hinted that making the DOM readonly would cause all kinds of problems, such as: a mutation listener that attempted to set certain global variables would throw an exception. I'm coming at this from the perspective of DOM Core and haven't gotten into the details of HTML yet, so I don't understand what these problems are. Could you provide more detail? Note that this isn't a capability system: we don't have to prevent the listener from having any access to the DOM. That wouldn't be possible and the listeners need read access to the document and its nodes. We just need to make any modification attempts fail. David
Received on Tuesday, 5 July 2011 19:01:21 UTC