[whatwg] Window and WindowProxy

[Ian Hickson]

On Wed, 7 Aug 2013, Boris Zbarsky wrote:
> 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.

I would imagine most languages other than JavaScript would break that 
invariant. What other problems would it break?


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

No, the global object is the Window, at least per the spec today. Why is 
this not accurate?

http://www.whatwg.org/specs/web-apps/current-work/#script's-global-object


> That's not actually compatible with ES because of how "var" needs to 
> behave in global scope.

Could you elaborate on this?


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

I don't understand what mapping behaviour you think is conceptually needed 
on Window.


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

I agree that these are good goals.


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

Straightforward isn't the word I would use, but ok.


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

It should act _exactly_ like Window. As far as I can tell, that means it 
_should_ proxy "proxy enumeration" and getOwnPropertyNames, whatever those 
are. Why do you think this is not the case?


> That's just not very clearly specified...  Again, I think we should just 
> clearly define the behavior of WindowProxy using the ES MOP primitives.

I have no idea what that means, but I'm certainly happy to do so if it 
makes sense.

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