Re: [heycam/webidl] Review handling of WindowProxy (#656)

>  That we assert that the JS value is not a Window object and when given a JS WindowProxy object, we return the IDL Window object for the JS WindowProxy's [[Window]] object?

This doesn't solve the point in https://github.com/heycam/webidl/issues/656#issuecomment-467541516. https://heycam.github.io/webidl/#dfn-create-operation-function step 2.1.2.2 never goes through ES type matching.

It also doesn't solve the problem where specs assume they are operating on IDL `Window` objects. (E.g., in the method/getter/setter steps for `Window` or `WindowOrWorkerGlobalScope` IDL operations/attributes.) Right now step 2.1.2.4 says

> Set idlObject to the IDL interface type value that represents a reference to esValue.

If that step was replaced with a proper type conversion (which is probably a good idea), then your suggestion would solve that problem.

> And that an IDL Window object is mapped back to a JS WindowProxy object (it seems this would have to go through the browsing context which isn't ideal).

This is probably also a good idea, for making more rigorous APIs that return `Window` objects like `top`, `open()`, `messageEvent.source`, etc. However currently the prose for most of those algorithms returns `WindowProxy` objects directly... would you want to change it to return `Window` objects, and then have IDL convert them back? That seems a bit indirect.

Currently I think HTML often hand-waves going from Window to WindowProxy, e.g. https://html.spec.whatwg.org/#posting-messages:windowproxy or https://html.spec.whatwg.org/#timers:windowproxy or https://html.spec.whatwg.org/#windowproxy-getownproperty:windowproxy-3. It's probably reasonable to formalize Window having a pointer back to its WindowProxy, if that ends up being helpful.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/656#issuecomment-685974403