[whatwg] Window and WindowProxy

[Ian Hickson]

On Tue, 6 Aug 2013, Boris Zbarsky wrote:
> 
> As currently specified, the setup for Window/WindowProxy is as follows:
> 
> 1) WindowProxy is specified as "all operations that would be performed 
>    on it must be performed on the Window object of the browsing 
>    context's active document instead", whatever that means in ES-spec 
>    terms.
> 
> 2) Window has an indexed getter on it and does security checks of 
>    various sorts on property access.
> 
> There is a somewhat different way to specify this:
> 
> 1) WindowProxy has the indexed getter behavior and does security checks 
>    as needed.
> 
> 2) Window has no magic at all.
> 
> Right now, these two ways of specifying it are black-box equivalent, but 
> this equivalence relies on the following three invariants holding:
> 
> A) "var foo;" is not valid ES for any value of foo that would be 
>    considered a valid argument to the indexed getter.
> 
> B) Bareword "foo" is not valid ES for any value of foo that would be 
>    considered a valid argument to the indexed getter.
> 
> C) Script can never get its hands directly on a Window object.
> 
> Invariants B and C together mean that the only way to invoke the indexed 
> getter is via the WindowProxy.  Invariant A means that there is no 
> contradiction between the way ES specifies var (as creating 
> non-configurable properties) and the WebIDL requirements for an object 
> with an indexed getter (not allowing definition of any "expando" indexed 
> properties at all).

I think there are other invariants that make them equivalent that are 
relevant here. In particular:

D) When a Window is a script's global object, that script is always going 
   to be same-origin with the Window, so it will always pass the security 
   checks. (So, it's ok to not do the checks on Window and do them on 
   WindowProxy instead.)

I think actually invariants A and B are mooted by invariant D. That is, if 
they weren't true, we'd still be ok, because the security check is always 
going to be safe given D.

But if invariant D was broken, then it seems like A and B would become 
problematic if we moved the security checks to the WindowProxy rather than 
to the Window.

If invariant C is broken, e.g. because in some new language we don't have 
a WindowProxy and instead return the real Window for the current Document, 
or whatnot, whenever you access the Window object, it seems like we'd also 
actually want the security checks on Window.

Do these last two points affect your conclusions?


> I believe the model that puts all the magic in the WindowProxy, which 
> has to be quite magical already, is much easier for implementors to 
> understand and reason about, and more clearly maps onto actual 
> implementations with an actual proxy for the WindowProxy. It has the 
> benefit of not depending on hidden invariants to avoid contradicting the 
> ES spec, and of making it clear exactly where the magic is, as well as 
> the small but tangible side benefit of making the global (in the ES 
> sense) not be an "exotic object" (also in the ES sense), thus reducing 
> the likelihood that future ES changes to how the global behaves will in 
> any way affect the behavior of "window".
> 
> The drawback is that it needs a bit more prose defining the behavior of 
> WindowProxy....

It doesn't seem like that much more prose, at least, not if we're keeping 
the same level of precision. (If we want more, that's a different matter.)


What do other vendors think? This is in principle a purely editorial 
change. It would be cool if there was a WebIDL way to define WindowProxy, 
so that it could be unambiguously defined for all languages, but since 
it's a one-off object, maybe it's not worth it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'