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

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

--- Comment #66 from Dominic Cooney <dominicc@chromium.org> ---
(In reply to Bobby Holley (:bholley) from comment #65)
> (In reply to Dominic Cooney from comment #62)
> 
> > (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.
> 
> Would detachedCallback fire in that case?

Probably, but I don't know.

> I'm certainly happy to add whatever callbacks we need here. But IIUC, the
> issue is less that authors want to be notified about adoption, and more that
> state during the detachedCallback in that case is confusing. We could
> certainly say "if you want to be sure to hear when your document is removed
> from the DOM, you need to have both a detachedCallback and an
> adoptedCallback". But that's probably pretty annoying, and most developers
> will probably just skip it, and get confused when their element disappears
> via an adopt.

Probably. There's no element death callback, so maybe being adopted away is
like that?

> > > 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.
> 
> I don't think we're seeing eye to eye here. Here's how I read the sequence
> of events in this bug:
> 
> (1) Anne proposes speccing prototype swizzling for concept-adopt-node
> (applying to all DOM nodes, not just custom elements). Discussion ensues.
> bholley makes a lot of noise about leaks.
> 
> (2) In comment 37, Domenic requests that we consider Web Components as a
> stakeholder in this discussion. He reports that Web Components had trouble
> defining the callbacks semantics for adoptNode, and punted on prototype
> swizzling.
> 
> (3) bholley proposes special-casing Web Components by making it illegal to
> adopt them.
> 
> (4) In comment 51, Dmitri expresses his dismay with (3), and says that we
> should make Web Components behave as much like the rest of the DOM as
> possible.

FWIW I agree with Dimitri. I think it's weird if you can't adopt Custom
Elements like any other kind of element.

> (5) bholley provides Telemetry data indicating that prototype swizzling is
> required in the general case to prevent unacceptably-large leaks.

I don't think this quite follows... I saw data about leak frequency, but not
size. But I'm with you that all things being equal it is better not to leak.

> (6) In comment 57, Domenic signals his intention to go back to work on the
> Web Components spec to come up with a solution for custom elements.
> 
> Does this match your interpretation? If not, what am I missing?

Modulo the inline comments that's it. I wasn't able to come up with something
better. I think developers on Chrome are happy their Custom Elements continue
to work in other documents--even that is probably a rare case--and they always
bear the cost of leaks in general because Chrome doesn't do any prototype
resetting.

> > > 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.
> 
> This is what I want to avoid, at least for non Custom Elements. In this
> sentence, I read "if something like that exists" as "if a custom element is
> adopted cross-global". Is that correct?

In the status quo, that's correct.

Do you have any data to share about the size of the JavaScript state versus the
DOM state?

> In the light of comment 56, I would wager that it is more likely than not
> that swizzling will get specced for the DOM in general. If that does happen,
> the options I can think of for Custom Elements are:
> (A) Swizzle the prototypes. If a Custom Element with the same name been
> registered the new scope, the prototype points to that. Otherwise, the
> element loses its magic. This approach requires figuring out the semantics
> of |detachedCallback|.

This is basically right. You're proposing a relatively specific solution
here--that if the names are equal, then one definition should be substituted
for another. There might be specific tweaks to a solution in this area that
makes authors happier.

> (B) Leave the prototype in the old scope for Custom Elements. This leaks,
> and makes Custom Elements more special, but might be more friendly to web
> developers.

It would be nice to not add more magic (although it's only magic if other nodes
behavior changes... FWIW this matches most closely what Chrome does today.)

> (C) Forbid adoption. This is easy, but probably makes Custom Elements too
> special to re-implement existing things like marquee.

This is what Dimitri was arguing against as you noted above, etc.

> I think (A) is the best option if we want Custom Elements to be first-class
> citizens.

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

Received on Friday, 17 January 2014 00:35:49 UTC