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

Proxy transparency has a bunch of weird implications. The most obvious one is that you’d now have two objects floating around which both ‘are’ the same element yet are not the same object. But there are much more subtle issues which relate to the concepts of membranes and information side channels which I skipped over earlier because I don’t think I understand them well enough to actually explain them. However searching for some of those words together (membrane, proxy, etc) would likely turn up good info on the subject. It gets kinda heady though.

In any case you’d still have the target leak issue on account of the unupgraded element (the target) being potentially accessed before the upgrade took place, and the issue of replacing that target everywhere it gets exposed in the DOM with a different object, e.g. in NodeList instances.

I would say that this isn’t really an inconsistency, even though I feel what you’re saying and agree that it would be great if we had some mechanism to achieve this stuff. In precludes authoring any classes that inherit from platform interfaces which in turn implement stuff like Web IDL getter behaviors, which is limiting when it comes to implementing certain platform APIs/polyfills in the ES layer, a subject I’m super interested in. But there’s a huge amount of thought that went into this design and its limitations stem from the need to ensure certain truths hold (it’s actually closely related to some of the stuff in that other thread, about making sure the ES object model continues to permit ... I don’t know the right word for it, ‘zones of control’ is the best I can think of).

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