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

Boris Zbarsky bzbarsky at
Tue Jan 27 17:53:50 PST 2015

On 1/27/15 4:44 PM, Mark S. Miller wrote:
> Since the WindowProxy is not a Proxy, or more relevantly, even if it
> were a Proxy, the underlying Window is not its target, we can even do
> the following:
> When the WindowProxy sees the defineProperty with the omitted
> "configurable:" and determines that the underlying Window does not
> already have this property. WindowProxy can even preserve the
> unwarranted intent expressed in the comment by actually defining a
> *non-configurable* own property on the Window itself. However, the
> behavior of the WindowProxy is not observably different than our Proxy
> example: It acts as if it created a configurable own property on the
> WindowProxy of this same name, and then proceeds with the normal
> defineProperty behavior, which preserves that alleged configurability.

I'd like to understand better the suggestion here, because I'm not sure 
I'm entirely following it.  Specifically, I'd like to understand it in 
terms of the internal methods defined by 

Presumably you're proposing that we keep all of that as-is except for 
[[DefineOwnProperty]], right?

For [[DefineOwnProperty]], are we basically talking about changing step 
1 to:

1)  If the [[Configurable]] field of Desc is present and 
Desc.[[Configurable]] is false, then throw a TypeError exception.

while keeping everything else as-is, as opposed to the behavior I'd 
understood we were aiming for, which was:

1)  If the [[Configurable]] field of Desc is not present or 
Desc.[[Configurable]] is false, then throw a TypeError exception.

?  If so, that's certainly a change that is much more likely to be 


More information about the es-discuss mailing list