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: Thu, 13 Dec 2012 14:39:49 -0500
Message-ID: <50CA2F05.9000801@mit.edu>
To: "Mark S. Miller" <erights@google.com>
CC: Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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_.  I don't think there's anything we care about defining on the 
WindowProxy.

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.

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.

This seems like it maintains all the various invariants, right?  Is it 
useful behavior?

-Boris
Received on Thursday, 13 December 2012 19:40:20 UTC

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