whatwg / webidl

Web IDL Standard
https://webidl.spec.whatwg.org/
Other
406 stars 164 forks source link

Review handling of WindowProxy #656

Open Ms2ger opened 5 years ago

Ms2ger commented 5 years ago

@bzbarsky opens this can of worms in https://github.com/heycam/webidl/pull/654#discussion_r259869833.

Probably every instance of "implements" or "is a platform object" should allow WindowProxy.

domenic commented 5 years ago

Moving https://www.w3.org/Bugs/Public/show_bug.cgi?id=29386 to here; see there for a bit of background.

TimothyGu commented 5 years ago

https://github.com/whatwg/html/issues/3997 might also be of interest.

annevk commented 5 years ago

So conclusions from last time:

What is the reason that "implements" and "is a platform object" need to deal with WindowProxy?

Ms2ger commented 5 years ago

I guess they might not need to if we don't allow Window as input or return values; except for this-brand-checks? I was assuming we'd keep using Window there.

bzbarsky commented 5 years ago

What is the reason that "implements" and "is a platform object" need to deal with WindowProxy?

Here's a simple example. Let's say I do:

  window.addEventListener("foo", () => {});

What should happen? When addEventListener is called we land in the steps defined in https://heycam.github.io/webidl/#dfn-create-operation-function step 2.1. In step 2.1.2.4, O is the WindowProxy. So as currently written that check will fail, since a WindowProxy tests false for "is a platform object". That's not the behavior we want.

annevk commented 5 years ago

So I was thinking I could give WindowProxy a [[PrimaryInterface]] slot, but that does not work as there's no WindowProxy interface (it would work for "is a platform object" since it doesn't look at the value though).

annevk commented 4 years ago

Could an alternative be to tackle this through https://heycam.github.io/webidl/#es-type-mapping? 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? 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).

domenic commented 4 years ago

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).

At first this seemed like 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. The current status quo seems reasonable in that regard.

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.