[whatwg] Window and WindowProxy
Boris Zbarsky
bzbarsky at MIT.EDU
Sun Aug 18 23:42:54 PDT 2013
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
More information about the whatwg
mailing list