[whatwg] DOM Range: redefining behavior under DOM mutation

On 3/30/11 1:50 PM, Aryeh Gregor wrote:
> Hmm, wait a sec.  I just reviewed the spec for insertBefore(), and I
> don't see any way this could happen.  If anything would prevent it
> from completing successfully, an exception is supposed to be thrown
> before anything else is done.  Under what conditions could it be
> removed from the old parent but not added to the new parent?

The spec we're looking at is 
<http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-insertbefore> 
as of March 26, I assume?  This spec is all kinds of broken if you allow 
userdata handlers and mutation events.

For example, consider the following situation:

  a.insertBefore(b, null);

where a.ownerDocument == A, b.ownerDocument == B, A != B, and b has a 
userdata handler that calls B.adoptNode(b) if b is adopted out of 
document B.

In this situation, following the spec algorithm will insert 'b' as a 
child of 'a' even though they have different owner documents.  That's 
broken.

Or consider a situation where a mutation listener on some ancestor of 
'b', or a userdata handler on 'b', performs any operation which puts the 
DOM into a state where any of the checks in steps 3 or 4 of the 
algorithm fail.  What's an implementation supposed to do then?

The way Gecko handles this right now is that if in step 7 script ends up 
performing any DOM mutations we go back and redo the integrity checks of 
steps 3 and 4, throwing as needed. We also throw if the owner document 
is not what it should be after the adoptNode call.  But at this point 
'b' has already been removed from the old parent.

>> The range is explicitly repositioned by the end of the surroundContents
>> algorithm.
>
> That would result in
>
>    <p><b>Foo</b><b>bar</b></p>
>
> but actually, the result in Gecko is
>
>    <p><b>Foobar</b></p>
>
> reusing the existing<b>  element.

Ah, I misunderstood what the result was.  Let me look up what Gecko 
actually does here and get back to you.

-Boris

Received on Wednesday, 30 March 2011 11:48:08 UTC