W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Mutation events replacement

From: David Flanagan <dflanagan@mozilla.com>
Date: Tue, 05 Jul 2011 12:00:52 -0700
Message-ID: <4E135F64.2080900@mozilla.com>
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.

Received on Tuesday, 5 July 2011 19:01:21 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC