Re: [DOMCore] ownerDocument of a Document object

On 06/06/2011 04:48 PM, David Flanagan wrote:
> On 6/5/11 5:06 PM, Boris Zbarsky wrote:
>> On 6/3/11 2:44 PM, David Flanagan wrote:
>>> Also, the final step of the ensure algorithm is this:
>>>> If old's |ownerDocument
>>>> <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-ownerdocument>|
>>>>
>>>> and new's |ownerDocument
>>>> <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-ownerdocument>|
>>>>
>>>> are not the same, throw a |HIERARCHY_REQUEST_ERR
>>>> <http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-hierarchy_request_err>|
>>>>
>>> It seems to me that the previous steps of the algorithm ensure that they
>>> are the same and that this step is not necessary.
>>
>> Unfortunately, no. Invoking adoptNode can trigger arbitrary script
>> execution before it returns in several different ways, which can
>> change the ownerDocument of both 'new' and 'old'. Changing the
>> ownerDocument of 'old' while not messing with 'new', in particular,
>> will make the ownerDocuments not match.
>>
>> -Boris
>>
> Really? Because of mutation events? Fired synchronously? I believe that
> the latest DOM events spec draft has made mutation events optional. It
> seems to me that DOM Core is the place to define them (since it defines
> all the mutation methods) if they were going to be included in this
> spec... I'd argue that this spec doesn't need to include language that
> is only necessary on implementations that have implemented features
> outside of the spec.
>
> Or am I missing some other way that adoptNode can cause script execution?

In the current stable specs (DOM 2 Events, DOM 3 Core) user data
handlers and mutation event listeners can cause script execution.

Note, even if we should get rid of mutation events, that won't happen 
before we have a good replacement for them. DOM 3 Events does
deprecate mutation events, but IIRC, the requirement is that there is a
replacement for them before D3E can become recommendation.
(The replacement will hopefully allow script execution only at "stable" 
times)


-Olli


>
> David
>
>

Received on Monday, 6 June 2011 14:29:11 UTC