[whatwg] Window and WindowProxy

[Boris Zbarsky]

On 8/13/13 4:34 PM, Ian Hickson wrote:
> I see that this is a requirement in the JS spec, but I don't understand
> why, other than providing a sane API

That's why, basically.  Providing something that guarantees at least 
_some_ invariants that things that want to enforce other invariants can 
then build on.

> It also doesn't appear to be enforced in proxies

I believe the intent of ES6 proxies is in fact to enforce these 
invariants.  Deviations from that, if there are any, are presumably spec 
bugs.

> unless I'm missing something (indeed the spec says "it is
> possible to define a proxy object whose handler methods violates the
> invariants", which seems to explicitly contradict this.)

It then goes on to say "These invariants are explicitly enforced by the 
proxy internal methods specified in this section".  As in, even if your 
handler tries to violate the invariants, the ES implementations is not 
supposed to let it do that.

For example, see ES6 section 8.5.5 step 21 for what happens if your 
handler tries to claim a property is non-configurable without it 
actually being non-configurable on the target object.  And see step 12 
for making sure the handler can't claim to not have a property if it's 
non-configurable on the target object.  The combination of those two is 
that once the proxy successfully claims a property is non-configurable, 
the property can't go away.

>>>> in that situation two different origins become the same origin and
>>>> the fact that they have different Window objects for the same
>>>> current window ends up observable.
>>>
>>> Well, what the spec says now is that when the script changes effective
>>> origin, it also changes its prototypes and so forth, essentially.
>>
>> Does any UA do this?  I would be somewhat surprised if this were web
>> compatible, and even more surprised if it were implementable in practice
>> and if any UA wanted to implement it....
>
> No idea. What should we do instead? What do browsers do?

What Gecko does is that there is a set of canonical prototypes (the DOM 
ones, Object.prototype, Array.prototype, etc) per global.  The effective 
script origin of a global is mutable.  The effect of changing the 
effective script origin of a global on the prototypes associated with 
that global is that nothing at all happens to them: they stay as the 
same objects.

Now what happens to actual objects and their proto chains when they go 
from being same-effective-script-origin to not or back...  I'm not 
actually sure.  Bobby Holley probably knows, though; I think this is 
basically the situation he's talking about in 
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c38>.

>> Sure, but changing this makes it very hard to reason about ES, in very
>> undesirable ways.  This has been pretty extensively hashed out on
>> es-discuss and public-script-coord...
>
> When it was hashed out, what was the conclusion with respect to what to do
> for cross-origin objects, Window, and the dichotomy between Window,
> WindowProxy, "this" in main code, and the global object?

_That_ part is still being sorted out, unfortunately, since none of that 
is part of ES-the-language per se.  :(  Yes, this is suboptimal.  Again, 
please see the discussion at 
<http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html> 
and following.

> How are the invariants preserved in JS-backed Proxies?

See above.

>> The WindowProxy is the object the script has.  It's the object
>> [[GetOwnProperty]] (via Object.getOwnPropertyDescriptor) is called on.
>
> Proxies can override [[GetOwnProperty]], though, to return whatever they
> want.

Not quite whatever they want: they in fact can't override it to violate 
certain invariants.

-Boris