Re: WindowProxy objects violate ES5 invariants

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