Figuring out the behavior of WindowProxy in the face of non-configurable properties

David Bruant bruant.d at
Tue Dec 2 05:24:01 PST 2014


I feel like I've been in an equivalent discussion some time ago, so 
taking the liberty to answer.

Le 02/12/2014 13:59, Andreas Rossberg a écrit :
> On 1 December 2014 at 03:12, Mark S. Miller <erights at> wrote:
>> On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky <bzbarsky at> wrote:
>>> Per spec ES6, it seems to me like attempting to define a non-configurable
>>> property on a WindowProxy should throw and getting a property descriptor for
>>> a non-configurable property that got defined on the Window (e.g. via "var")
>>> should report it as configurable.
> Can you clarify? Do you mean that it should report properties as
> configurable, but still reject attempts to actually reconfigure them?
Yes. This is doable with proxies (which the WindowProxy object needs to 
be anyway).
* the defineProperty trap throws when it sees configurable:false
* the getOwnPropertyDescriptor trap always reports configurable:true
* and the target has all properties actually configurable (but it's 
almost irrelevant to the discussion)

> Also, how would you allow 'var' to even define non-configurable
> properties? If you want DefineProperty to throw on any such attempt,
> then 'var' semantics would somehow have to bypass the MOP.
Thinking in terms of proxies, the runtime can have access to the target 
and the handler while userland scripts only have access to the proxy 
(which the HTML Living standard mandates anyway with the difference 
between Window and WindowProxy objects. No userland script ever have 
access to the Window object).
The handler can have access to the list all declared variable to know 
which property should behave as if non-configurable.


More information about the es-discuss mailing list