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 02:08:42 +0100
Message-ID: <50CBCD9A.7080007@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 13/12/2012 20:39, Boris Zbarsky a écrit :
> On 12/13/12 1:50 PM, Boris Zbarsky wrote:
>> On 12/13/12 1:32 PM, Mark S. Miller wrote:
>>> The invariants say that you cannot claim to be non-configurable and
>>> then have observable changes that should have been possible. The
>>> invariants purposely allow the opposite "violation": a property can
>>> claim to be configurable but still refuse to be configured.
>> Interesting.  That would require some extra magic to keep track of
>> properties that are "really" non-configurable (in terms of behavior)...
> I've thought about this some more, and here's where I am now:
> 1)  UAs need to be able to define non-configurable properties on the 
> _Window_.
Yes. More specifically, then don't need to do it dynamically, they just 
need to initialize one object with the right set of non-configurable 

> I don't think there's anything we care about defining on the WindowProxy.
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. In ES6, it would just be a proxy. Reusing Jason 
Orendorff's code [1], I would express WindowProxy pretty much like 
I'm probably missing some traps, the same origin policy isn't 
implemented (it would probably take ~10 lines though), getters/setters 
are missing their code, all [Unforgeable] properties aren't listed, etc.
The idea is that the script-exposed WindowProxy is only the "proxy" part 
of what's returned by calls to the WindowProxy function. All the rest 
would be internal to the engine. Including "setTarget", the Window 
constructor, etc. setTarget would be used whenever the platform needs to 
change the underlying window (like window.open, or change of iframe@src).

In that way of seeing things, WindowProxy is just a proxy, so nothing 
can be defined "on it". It doesn't have properties at all. It just 
forwards to the current target.

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.

> 2)  Given that, I think it would be fine to always have WindowProxy 
> throw if an attempt is made to define a non-confirable property on it.

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

> 4)  Trying to set/define properties on WindowProxy would just forward 
> to the Window, modulo #2 above, which would sometimes throw even 
> though the property claimed to be configurable.

> 5)  Trying to seal/freeze the WindowProxy throws, I guess, possibly 
> after doing a seal/freeze on the Window.
In my case, I don't seal/freeze the underlying window. I don't really 
know if it matters. Refusing entirely is probably the safest thing to do.

> This seems like it maintains all the various invariants, right?
I think so.

> Is it useful behavior?
I guess more useful than if invariants were broken. Practically 
speaking, I don't think most web authors will see the difference.


[1] https://gist.github.com/4279162
Received on Saturday, 15 December 2012 01:09:15 UTC

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