- From: <bugzilla@jessica.w3.org>
- Date: Fri, 26 Jul 2013 00:26:30 +0000
- To: public-script-coord@w3.org
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