RE: Adopting a Custom Element into Another Document

2015-01-14 Thread Domenic Denicola
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  and such. If the  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

2015-01-14 Thread Anne van Kesteren
On Tue, Jan 13, 2015 at 8:43 PM, Domenic Denicola  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  and such. If the  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

2015-01-14 Thread Anne van Kesteren
On Tue, Jan 13, 2015 at 8:36 PM, Ryosuke Niwa  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

2015-01-13 Thread Ryosuke Niwa

> On Jan 13, 2015, at 11:43 AM, Domenic Denicola  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

2015-01-13 Thread Boris Zbarsky

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

2015-01-13 Thread Domenic Denicola
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  wrote:

> On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa  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

2015-01-13 Thread Ryosuke Niwa
On Jan 13, 2015, at 11:27 AM, Anne van Kesteren  wrote:

> On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa  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

2015-01-13 Thread Anne van Kesteren
On Tue, Jan 13, 2015 at 8:15 PM, Ryosuke Niwa  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

2015-01-13 Thread Ryosuke Niwa
On Jan 13, 2015, at 7:05 AM, Anne van Kesteren  wrote:

> On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa  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

2015-01-13 Thread Anne van Kesteren
On Tue, Jan 13, 2015 at 6:15 AM, Ryosuke Niwa  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/