[whatwg] DOM Range: redefining behavior under DOM mutation
bzbarsky at MIT.EDU
Wed Mar 30 11:48:08 PDT 2011
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
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:
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
In this situation, following the spec algorithm will insert 'b' as a
child of 'a' even though they have different owner documents. That's
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
> That would result in
> but actually, the result in Gecko is
> 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.
More information about the whatwg