Review handling of WindowProxy

[Ms2ger]

@bzbarsky opens this can of worms in #654 (comment).

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

[domenic]

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

[TimothyGu]

whatwg/html#3997 might also be of interest.

[annevk]

So conclusions from last time:

• Forbid IDL fragments from using Window as input or return value
• Whenever IDL is passed a WindowProxy, perform the security checks on its [[Window]] internal slot value

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

[Ms2ger]

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]

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]

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]

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]

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 #656 (comment). 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.