W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Window and WindowProxy

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 13 Aug 2013 20:34:56 +0000 (UTC)
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Message-ID: <alpine.DEB.2.00.1308132005090.27623@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Thu, 8 Aug 2013, Boris Zbarsky wrote:
> On 8/8/13 5:05 PM, Ian Hickson wrote:
> > I think the problem is that I have no idea what these ES6 terms are or 
> > what they mean.
> 
> OK.  Which terms, exactly?

Probably all the JS terms that were introduced since the late 90s...

(Thanks for the education in your e-mail. Much appreciated.)


> In particular, if [[Configurable]] is false, then the values of 
> [[Configurable]], [[Enumerable]], [[Get]], [[Set]], and [[Writable]] for 
> this property cannot change in the future ([[Value]] can still change if 
> this is a value property that is [[Writable]]).

I see that this is a requirement in the JS spec, but I don't understand 
why, other than providing a sane API (which we've also given up on as far 
as Window goes... the object can randomly change identity right from under 
you while your code is running). It also doesn't appear to be enforced in 
proxies, 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.)


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


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

How are the invariants preserved in JS-backed Proxies?


> > > If an object (in this case a WindowProxy, since that's what the 
> > > script is working with) ever claims that it has a non-configurable 
> > > property for some property name, ES requires that it _always_ do 
> > > that from that point on.
> > 
> > That's fine. The Window will keep having that property. The 
> > WindowProxy object's own properties can't be examined
> 
> 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. So why don't we override it to defer to Window?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 13 August 2013 20:35:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC