W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2013

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 18 Oct 2013 00:36:54 +0000
To: public-script-coord@w3.org
Message-ID: <bug-20567-3890-KKL1nEAQJT@http.www.w3.org/Bugs/Public/>

--- Comment #44 from Dominic Cooney <dominicc@chromium.org> ---
(In reply to Bobby Holley (:bholley) from comment #43)
> (In reply to Dominic Cooney from comment #42)
> > And I don't know to what extent the cases discussed here cause leaks.
> If we go with (1), then implementations will be required to keep the old
> global alive as long as the adopted node exists in a live document.

I understand how the leak arises. I don't know how much it happens in practice.

> As partially noted in comment 41, I believe there are two approaches that
> would resolve Boris' worries about throwing midway through a recursive adopt:
> (A) Don't throw when adopting ancestors of Custom Elements, but don't adopt
> the Custom Elements either. They get ejected from the document, but they
> (and their children) remain owned by the original document and don't appear
> in the subtree handed to the new document.
> (B) Maintain a bit at each node indicating whether that node has Custom
> Elements in its descendants, and throw immediately when we try to adopt such
> a node. We'd only have to do work to compute this bit when applying/removing
> bindings and inserting/removing Custom Elements from the tree, neither of
> which are performance-critical operations. The algorithm would be
> O(TreeDepth*AverageChildCount), and very fast in practice.

It is very common to adopt subtrees containing Custom Elements across
documents. A typical web component's UI is cloned out of a template (template
document) and adopted into the custom element's shadow DOM (main document.) So
I don't think throwing is feasible.

> > re: Comment 41, compatibility is one constraint. I don't think the absence
> > of compatibility constraints gives us a free pass on developer ergonomics.
> I am highly resistant to speccing memory leaks for the sake of developer
> ergonomics - it is very unlikely that developers will understand, care, or
> even notice the fact that adoptNode would increase memory footprint (not to
> mention all the sites that already use adoptNode). So they ship, and then
> users blame their browser for being bloated.
> I feel strongly about this particular issue because the scope of the memory
> leaks (all cross-global adopts) is much wider than the scope of the feature
> and ergonomics they'd be supporting (leftView semantics for Custom Elements
> being adopted cross-global).

I think we should look for a solution that doesn't involve a bad compromise.
Basically, something that works for web developers and doesn't leak. I don't
think these things are incompatible.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 18 October 2013 00:36:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC