[whatwg] Window and WindowProxy

[Boris Zbarsky]

On 8/7/13 5:18 PM, Ian Hickson wrote:
> We could indeed move the indexed properties to WindowProxy, while leaving
> the security checks (which apply to non-indexed properties only) on
> Window. This would still address my concern, which is that if we move the
> security checks to WindowProxy, and then break the invariant whereby you
> can't actually get to a cross-origin Window directly

If we break that invariant, fwiw, then I suspect we have much bigger 
problems.

> Would it address your concerns?

I think it would be a step up from where we are right now...

> (I'm not sure I 100%
> understand what those are yet, i.e. why you want this moved.)

Because the current spec effectively calls for the global to be a 
proxy-like object (or some sort of object that's not describable in ES 
spec terms at all, of course, but the idea of ES proxies is to be able 
to describe anything remotely sane).  That's not actually compatible 
with ES because of how "var" needs to behave in global scope.

So it seems to me that any implementor trying to implement this spec 
will go to their favorite ES implementation and discover that the spec 
cannot be implemented as written and must instead be mapped to some 
other conceptual model.  After thinking about it for a bit, the only 
obvious way to avoid having proxy-like behavior on the Window is to put 
it all on WindowProxy, which _already_ has proxy-like behavior no matter 
what.

At which point, I think we should spec it that way, for two reasons:

1)  It reduces the burden on implementors trying to understand this part 
of the spec and map it to what ES will let them do.

2)  It reduces the likelihood that some modification to ES or the 
Window/WindowProxy specs will in fact make things unimplementable 
altogether in the future.

> The difficulty with moving just the indexed properties are that "length"
> would now be on a different object than what it describes.

I don't think that's a problem, honestly.  "length" on a Window returns 
the number of child windows.  An indexed access on a WindowProxy returns 
the corresponding child of its current Window.  It seems fairly 
straightforward...

> Also, it would
> complicate the WindowProxy magic -- now, instead of it just being a proxy,
> it would be a proxy except for certain properties.

Indeed.  Of course WindowProxy is already not "just a proxy": it doesn't 
transparently proxy enumeration or getOwnPropertyNames, for example. 
That's just not very clearly specified...  Again, I think we should just 
clearly define the behavior of WindowProxy using the ES MOP primitives.

> Can you elaborate on what the problem is with the current approach?

Does the above help?

-Boris