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

Re: WindowProxy objects violate ES5 invariants

From: David Bruant <bruant.d@gmail.com>
Date: Sat, 15 Dec 2012 14:36:47 +0100
Message-ID: <50CC7CEF.9040403@gmail.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: "Mark S. Miller" <erights@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Le 15/12/2012 03:10, Boris Zbarsky a écrit :
> 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.
I'm not sure I have fully understood this, but I'm interested in hearing 
more.
With ES6 proxies, it's would be possible to make the same-origin check 
in a meta-handler (a handler which is itself a proxy [1]) and throw the 
security exception there (that's the 10 lines I was talking about). This 
way, the exception is thrown before the access to the underlying window. 
It is so true that the underlying window doesn't even need to be set as 
target.
The downside is that if proxies aren't optimized, same-origin accesses 
need to go through 2 levels of handlers before reaching the actual 
object. This may have some cost.

> 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 possible).
Ok. I understand. That's an implementation concern indeed and as long as 
it doesn't have observable consequences, all freedom is allowed.

>> 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 can see the performance problems especially if proxies aren't 
optimized, but I don't understand what you're calling "convenience".

>>> 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.
Annoying for maintainability? for performance? In the draft 
implementation I show, I made it as easy as a .hasOwnProperty call. It 
doesn't sound that annoying.
That point is important. If WindowProxy can reflect [Unforgeable] 
properties as configurable, then it changes the definition of 
[Unforgeable]. Or maybe it needs to be split into 2 definitions.

David

[1] https://gist.github.com/3854020#file-membrane_getprototypeof-js-L11
Received on Saturday, 15 December 2012 13:37:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:08 UTC