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

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

--- Comment #49 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Erik Arvidsson from comment #48)
> Complexity: We now need to enumerate all the properties of which we need to
> change their values. What if this object is shared between different realms?
> For example I have a two elements using the same value for their onclick
> webidl attribute. Am I supposed to change the prototype of it?

No, I think the handler should not be adopted. Per comment 36 I think we can
probably just clear event handlers and listeners on cross-global adopt.

In general, the I think that 'owned' things (like .style - a short list, I'd
think) should move, whereas 'unowned' things (like event handlers) should not.
Though given that (per comment 3) IE doesn't currently preserve .style identity
across reparents, we probably have a lot of flexibility in what we do here.

> Consistency: This only happens for nodes that are adopted. What about other
> cross realm objects. What if I reference an object across the boundary
> without adopting it (maybe it cannot be adopted).

They're pretty distinct concepts, IMO. In one case, we're just referencing
something that clearly belongs somewhere else. In the other case, we're
actually changing ownership (visible in that ownerDocument changes).

> I think playing the memory leak card is distraction. If you have multiple
> realms that can reference each other there will be cross realm references.
> Both the GC and the app author needs to be aware of this so that they do not
> hold on to cross realm references longer than needed.

I think the semantics are pretty different. In one case, you're holding an
object alive by virtue of holding a live reference to it. Everybody is well
aware that this affects what the GC is able to collect.

In other other case, the object holds an entire realm alive just by virtue of
sitting in a document, even after it has supposedly been "adopted".

> Changing the
> [[Prototype]] on adopt is not going to make this problem go away. It might
> alleviate the problem a bit but I've yet to see any number on how much it
> will help in reality. People could always use importNode if they needed to
> get a new fresh clone in the new document.

I'm not saying we should encourage cross-scope adopts - I'm just concerned that
there are already a fair number of them out on the web.

> Better tools would probably be a
> better bang for the buck than changing the [[Prototype]].

Well, it depends whose buck. ;-) Mozilla and Microsoft already have this
machinery, so specing things the other way requires effort on the other side.
And at least for Gecko, it would be pretty non-trivial due to the changes in
invariants - probably equivalent to the amount of effort to implement prototype
munging in Blink.

In general, (2) seems like the "right" way to spec this if it's a feature that
we care to support, both from semantic and performance standpoints. The only
argument against the leak issue is "maybe people don't use this feature very
often".

I wouldn't be comfortable doing (1) unless we emitted a console warning and
officially deprecated cross-global adopts. I can run some Telemetry numbers to
see how much this happens on the web today, but only if the spec community is
actually gung-ho about such a deprecation effort.

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

Received on Friday, 18 October 2013 15:46:48 UTC