[whatwg] Window and WindowProxy
bzbarsky at MIT.EDU
Wed Aug 7 20:53:19 PDT 2013
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
> 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
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
> 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?
More information about the whatwg