[Bug 20567] Change [[Prototype]] for concept-node-adopt?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567

--- Comment #24 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to comment #23)
> > I think what he meant is that if "elem" is in Frame A, and x is in Frame B,
> > appending "x" to "elem" will result in creation and insertion of a new
> > element (let's call it "xA") as a child of "elem", so subsequent attempts to
> > remove "x" from "elem" will do nothing, since "x" won't actually be a child
> > of "elem".
> 
> OK, that's not the case -- at least not in the "new identity" scheme I
> proposed in Comment 12.
> 
> x and xA wrap the same underlying DOM node. Therefore elem.removeChild(x)
> succeeds.
> 
> The only thing that does not succeed is JavaScript identity comparison:
> 
> elem.insertBefore(x, elem.firstChild);
> elem.firstChild == x; // Surprisingly false.
> 
> To me, this seems like the least bad consequence of the three options.
> Option 1's giant leaks are a show-stopper, in my opinion. And Option 2 is
> simply net more surprising to me than the identity change.

Makes sense.

> Easy to grok: Moving a node between windows changes its JavaScript identity.
> 
> Hard to grok: Moving a node between windows causes some of the node's
> JavaScript properties to disappear, while preserving some others, the exact
> behavior depending on the type of the node and/or the types of its
> properties.

I suppose some surprise is to be expected in both option 2 and 3, since we're
revealing that an object the user is holding onto is not a typical JS object.
That is, unless the environment does exactly nothing (option 1), in which case
the TC39 people are happy.

Travis, Jonas -- would love to hear your thoughts on option 2 as explained in
comment 23.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 31 July 2013 22:42:15 UTC