W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 26 Jul 2013 00:26:30 +0000
To: public-script-coord@w3.org
Message-ID: <bug-20567-3890-nHkJ8rg8Iw@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567

--- Comment #23 from Geoffrey Garen <ggaren@apple.com> ---
> 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.

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 26 July 2013 00:26:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC