[whatwg] Window and WindowProxy

[Boris Zbarsky]

On 8/8/13 2:11 AM, Ian Hickson wrote:
> I would imagine most languages other than JavaScript would break that
> invariant.

Why are we suddenly worrying about languages other than JavaScript?

> What other problems would it break?

Let me think about this; it's been a while...

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

The current spec calls for the Window to be a proxy-like object, because 
that's the only way to implement the spec's indexed getter behavior.

>> That's not actually compatible with ES because of how "var" needs to
>> behave in global scope.
>
> Could you elaborate on this?

"var" needs to be able to define non-configurable properties.  Proxies 
don't necessarily offer useful guarantees about being able to define 
such properties on them, and in particular the behavior for index/named 
getters in WebIDL precludes definition of non-configurable properties of 
the corresponding kind on the relevant object.

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

I'm not sure what you mean.  The "mapping" that needs to happen is "how 
do I have a global that's not a magic proxy while being black-box 
compatible with the spec?"

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

It's a lot more straightforward than what we have now, in terms of 
interactions with ES...

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

Because getOwnPropertyNames should return the own properties of the 
object, but doing that on a WindowProxy for a cross-origin window should 
not in fact return the Window's own properties.

Or another similar issue: getting a property descriptor from a 
WindowProxy (for a same-origin window) should probably never claim to 
have a non-configurable property, because on navigation the property 
will in fact disappear and non-configurable properties are not allowed 
to do that in ES.  See 
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html 
and the threads it references.  But of course Window is required to be 
able to have non-configurable properties (see "var").  So WindowProxy 
can't just forward [[GetOwnProperty]] on to the Window.

That link above also talks about how WindowProxy should probably reject 
attempts to define non-configurable properties on it altogether, which 
is an obvious non-starter for Window because "var" needs to work...

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

How objects behave in ES are defined in terms of various internal 
operations.  The set of operations ... keeps changing.  It used to be 
there were [[Get]], [[Set]], etc.  Now, with property descriptors, there 
are lower-level primitives like [[GetOwnProperty]], [[DefineProperty]], 
[[Delete]].  For example, WebIDL defines the behavior of all its objects 
in terms of those three primitives.  These low-level primitivies and how 
they interact define the meta-object protocol (MOP) for the abstract ES 
virtual machine.

-Boris