Re: [w3c/webcomponents] Returning a Proxy from a Custom Element constructor (#857)

> the instance isn’t a different object from what’s around after upgrade. I.e. there’s no before element vs after element

That's what I was saying all along. So the same reference will be in any WeakMap, Array, Proxry target, jQuery cache, etc, and the upgrade process won't break that.

If Proxies were allowed in the engine, then the engine could be a special case where it can access `[[Target]]` of a proxy when you pass a Proxy to any DOM API. That would simply solve the problem, I think.

> So if return override were supported (for proxies or anything else), the implication is that the DOM would need to update to exchange the original element with the override object in various places, and yes, the target would have leaked.

I'm proposing something a little different: the only allowed return override should be Proxies that wrap the object created by the HTML engine. The DOM would _**not**_ exchange engine's element reference with any userland constructor return value.

Userland code would reference a Proxy, the internal engine would continue to reference the [[Target]] of any Proxy.

So the target won't leak, because the target is what the engine currently would have a reference to, if Proxies were allowed.

To sum it up:

- Internally, the engine would never have a reference to a Proxy.
- Externally, userland code can manipulate the element instance with a Proxy
- When userland code passes a Proxy into any DOM API, the HTML engine would not save any reference to that Proxy, it would have special access to get the `[[Target]]` out of the Proxy (which is the native element instance) and use it as it would normally.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/857#issuecomment-560025385