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

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

--- Comment #61 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Dominic Cooney from comment #60)

> Custom Elements are special because they have an author-supplied prototype
> and callbacks. This is pretty analogous to having an event handler, so maybe
> whatever solution works for event handlers could be adapted to apply to
> Custom Elements?

That seems reasonable, yes. But what about the issue you mentioned in comment
37 (the timing for firing detachedCallback)?

> Not sure if this interests you but I can tell you about the status quo with
> Custom Elements in Chrome:
> 
> Chrome doesn't swizzle the prototype when a node is adopted (not Custom
> Elements nor any other node.)

Right. We're trying to spec the swizzling (or lack thereof, though I would
non-neutrally contend that this side is losing in light of the leak data).

> But we also don't want to leak, so a Custom
> Element's callbacks only work as long as the context it was registered in is
> alive.
> 
> This means if you have an IFRAME, register X-A in there, and move an X-A
> into the parent frame's document its callbacks will keep working provided
> the frame is alive. If you remove the frame, the callbacks stop firing (and
> incidentally we free the IFRAME, its document, etc.) The element's prototype
> still points to the author-supplied one, though.

But doesn't the prototype live in the window in which it was registered? How
can you free the IFRAME if the element's prototype still points to an object in
its scope?

> I think the idea of a callback that lets the author switch an element's
> definition sounds promising.

Can you explain this more?

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

Received on Thursday, 16 January 2014 00:31:09 UTC