W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: WindowProxy objects violate ES5 invariants

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 14 Dec 2012 21:10:24 -0500
Message-ID: <50CBDC10.2050102@mit.edu>
To: David Bruant <bruant.d@gmail.com>
CC: "Mark S. Miller" <erights@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 12/14/12 8:08 PM, David Bruant wrote:
> I'm surprised that you bring this up, so I'd like to share the way I
> view things on this point before moving forward. The way I see it, a
> WindowProxy is nothing more than an empty shell forwarding to an actual
> Window instance.

That's a convenient way to think about it, yes, and the observable 
behavior needs to be the same as if this were the case, I believe.

In terms of the actual implementation, it might do additional things. 
For example, it might make sense to have the WindowProxy the same-origin 
checks guarding access to Window properties, so that bareword access in 
scripts doesn't have to perform such checks.  Or in the case of 
Gecko+SpiderMonkey I was planning to put the indexed getter on the 
WindowProxy, not on the window, because those property names can only 
come via the WindowProxy and putting them there means the Window itself 
doesn't have to be a proxy (which happens to be impossible in 
SpiderMonkey, but would be a performance annoyance even if it were 

> In ES6, it would just be a proxy. Reusing Jason
> Orendorff's code [1], I would express WindowProxy pretty much like
> https://gist.github.com/4290075

Sure.  That's a useful way to think about it conceptually, but actual 
implementations may do something different under the hood for 
performance or convenience reasons.

> I'm interested in opinions on the code I've written and if people were
> seeing things differently than how I've coded and described it.

See above.

>> 3)  WindowProxy should probably munge the property descriptor for
>> non-configurable Window properties to claim they're configurable if
>> it's asked.
> [Unforgeable] properties can be reported as non-configurable, there is
> no problem with that.

Detecting that might be annoying enough to not be worthwhile, though.

Received on Saturday, 15 December 2012 02:10:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC