RE: Adopting a Custom Element into Another Document
From: Anne van Kesteren [mailto:ann...@annevk.nl] Because it's very easy to move nodes from one tree to another and this happens quite a bit through iframe and such. If the iframe then goes away it would be a shame to have to leak it forever. This is all discussed to great extent in the aforementioned bug. It's no more or less easy than moving normal JS objects from one realm to another, and we don't `__proto__`-munge those.
Re: Adopting a Custom Element into Another Document
On Tue, Jan 13, 2015 at 8:43 PM, Domenic Denicola d...@domenic.me wrote: Why is the tree data structure embodied by the DOM any different? Because it's very easy to move nodes from one tree to another and this happens quite a bit through iframe and such. If the iframe then goes away it would be a shame to have to leak it forever. This is all discussed to great extent in the aforementioned bug. -- https://annevankesteren.nl/
Re: Adopting a Custom Element into Another Document
On Tue, Jan 13, 2015 at 8:36 PM, Ryosuke Niwa rn...@apple.com wrote: I'm not sure I understand what you mean by that. The name of the new class MyElementB isn't important. Do you agree that the author has to create a new class in B if there is no definition of MyElement there? Yes. But how do we even determine whether MyElement's defined in B? Who is we? And if did, how do we get the class's prototype? In the proposed setup the developer just gets an adopted callback and can then do whatever they want. Either cleaning up the giant memory leak or leaving it in. -- https://annevankesteren.nl/
Re: Adopting a Custom Element into Another Document
On Jan 13, 2015, at 11:43 AM, Domenic Denicola d...@domenic.me wrote: I imagine this has all been discussed before, but why do __proto__-munging when adopting cross document? That seems bizarre, and causes exactly these problems. When you put an object in a Map from another realm, it doesn't __proto__-munge it to that other realm's Object.prototype. Why is the tree data structure embodied by the DOM any different? Indeed, it's strange that we only do this for DOM nodes. Furthermore, copying a custom element's class definition into the destination document without leaking the source document's global object is hard since methods of the class may capture the global object. We need to do something inelegant like re-loading the script in the destination. - R. Niwa
Re: Adopting a Custom Element into Another Document
On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa rn...@apple.com wrote: By the same thing, do you mean that they will manually change __proto__ themselves? Yes. Let's say we have MyElement that inherits from HTMLElement and we're adopting an instance of this element (let's call it myElement) from a document A to document B; MyElement is currently defined in A's global object. I have two questions: Why did we decide to let custom elements handle this themselves instead of doing it in the browser? With two realms it's not a given that both realms use the same custom element registry. (As you acknowledge.) When myElement is adopted into B, there is no guarantee that MyElement is also defined in B. Does that mean MyElement may need to create another class, let us call this MyElementB, in the B's context that inherits from B's HTMLElement? Well, if you control both realms I would assume you would give the same name. Didn't Boris say Gecko needs to do this synchronously in order to enforce their security policy? I don't think that's conclusive, though if it turns out that's the case we would need different timing between normal and custom elements, yes. -- https://annevankesteren.nl/
Re: Adopting a Custom Element into Another Document
On Jan 13, 2015, at 7:05 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa rn...@apple.com wrote: As far as I tested, WebKit and Blink keep the old __proto__ while Gecko changes it to the adopted document's prototype. There is a bug in DOM component about this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 So, the basic agreement as I understand it: * Normal elements change their prototype during adoption * Custom elements get a callback to be able to implement the same thing By the same thing, do you mean that they will manually change __proto__ themselves? Let's say we have MyElement that inherits from HTMLElement and we're adopting an instance of this element (let's call it myElement) from a document A to document B; MyElement is currently defined in A's global object. I have two questions: Why did we decide to let custom elements handle this themselves instead of doing it in the browser? When myElement is adopted into B, there is no guarantee that MyElement is also defined in B. Does that mean MyElement may need to create another class, let us call this MyElementB, in the B's context that inherits from B's HTMLElement? Now the outstanding questions: * Should normal elements change their prototype at the same point in time custom elements have the opportunity to change theirs, or should it happen synchronously? Didn't Boris say Gecko needs to do this synchronously in order to enforce their security policy? * Does it make sense that when subclassing a normal element this automatic prototype changing aspect gets lost? Can I have an answer to my question 1 above first? - R. Niwa
Re: Adopting a Custom Element into Another Document
On Jan 13, 2015, at 11:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa rn...@apple.com wrote: By the same thing, do you mean that they will manually change __proto__ themselves? Yes. Let's say we have MyElement that inherits from HTMLElement and we're adopting an instance of this element (let's call it myElement) from a document A to document B; MyElement is currently defined in A's global object. I have two questions: Why did we decide to let custom elements handle this themselves instead of doing it in the browser? With two realms it's not a given that both realms use the same custom element registry. (As you acknowledge.) Okay. When myElement is adopted into B, there is no guarantee that MyElement is also defined in B. Does that mean MyElement may need to create another class, let us call this MyElementB, in the B's context that inherits from B's HTMLElement? Well, if you control both realms I would assume you would give the same name. I'm not sure I understand what you mean by that. The name of the new class MyElementB isn't important. Do you agree that the author has to create a new class in B if there is no definition of MyElement there? But how do we even determine whether MyElement's defined in B? And if did, how do we get the class's prototype? Didn't Boris say Gecko needs to do this synchronously in order to enforce their security policy? I don't think that's conclusive, though if it turns out that's the case we would need different timing between normal and custom elements, yes. Great. Thanks for the clarification. - R. Niwa
RE: Adopting a Custom Element into Another Document
I imagine this has all been discussed before, but why do __proto__-munging when adopting cross document? That seems bizarre, and causes exactly these problems. When you put an object in a Map from another realm, it doesn't __proto__-munge it to that other realm's Object.prototype. Why is the tree data structure embodied by the DOM any different? -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Tuesday, January 13, 2015 14:37 To: Anne van Kesteren Cc: Webapps WG; Boris Zbarsky Subject: Re: Adopting a Custom Element into Another Document On Jan 13, 2015, at 11:27 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa rn...@apple.com wrote: By the same thing, do you mean that they will manually change __proto__ themselves? Yes. Let's say we have MyElement that inherits from HTMLElement and we're adopting an instance of this element (let's call it myElement) from a document A to document B; MyElement is currently defined in A's global object. I have two questions: Why did we decide to let custom elements handle this themselves instead of doing it in the browser? With two realms it's not a given that both realms use the same custom element registry. (As you acknowledge.) Okay. When myElement is adopted into B, there is no guarantee that MyElement is also defined in B. Does that mean MyElement may need to create another class, let us call this MyElementB, in the B's context that inherits from B's HTMLElement? Well, if you control both realms I would assume you would give the same name. I'm not sure I understand what you mean by that. The name of the new class MyElementB isn't important. Do you agree that the author has to create a new class in B if there is no definition of MyElement there? But how do we even determine whether MyElement's defined in B? And if did, how do we get the class's prototype? Didn't Boris say Gecko needs to do this synchronously in order to enforce their security policy? I don't think that's conclusive, though if it turns out that's the case we would need different timing between normal and custom elements, yes. Great. Thanks for the clarification. - R. Niwa
Re: Adopting a Custom Element into Another Document
On 1/13/15 2:43 PM, Domenic Denicola wrote: Why is the tree data structure embodied by the DOM any different? The issue is not the tree structure but rather 1) what it means to have a certain document as your ownerDocument and 2) Whether there are footguns here that make it too easy for authors to accidentally entrain globals forever. But yes, this has all been discussed at great length... -Boris
Re: Adopting a Custom Element into Another Document
On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa rn...@apple.com wrote: Have you settled the question of what happens to a custom element that's adopted into another document? More or less... As far as I tested, WebKit and Blink keep the old __proto__ while Gecko changes it to the adopted document's prototype. There is a bug in DOM component about this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 So, the basic agreement as I understand it: * Normal elements change their prototype during adoption * Custom elements get a callback to be able to implement the same thing Now the outstanding questions: * Should normal elements change their prototype at the same point in time custom elements have the opportunity to change theirs, or should it happen synchronously? * Does it make sense that when subclassing a normal element this automatic prototype changing aspect gets lost? -- https://annevankesteren.nl/
