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

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

--- Comment #62 from Dominic Cooney <dominicc@chromium.org> ---
(In reply to Bobby Holley (:bholley) from comment #61)
> (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)?

By not changing the prototype the timing of the detachedCallback is a
non-issue, because there's only one set of callbacks. So they're consistent
with their prototype. This problem arises if you try to change the prototype
and callbacks.

(Presaging your question about an event for this reparenting...) I was
speculating that if there was a callback to say, hey, this element is switching
documents so authors can do what they want (switch definitions, drop
definitions, leak definitions) and are flexible about the timing of that (maybe
the prototype swizzling happens slightly after the element is in the new
document) that might be a workable solution. The problem is I'm not sure what
authors need here.

> > 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).

I'm not sure I'd frame it in terms of winning and losing... UAs today behave
differently in this area, whether by design or historical accident, and being
compatible would be good. But if we can't come up with something workable for
UAs then probably the incompatibility will continue to exist.

> > 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?

Right, if something like that exists, the object would leak.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 16 January 2014 01:54:44 UTC