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

Mark S. Miller erights at
Tue Jan 27 21:45:29 PST 2015

On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky <bzbarsky at> wrote:

> 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 <
> window-proxy-spec>.
> 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,

Exactly correct. I didn't realize until reading your reply is that this is
all that's necessary -- that it successfully covers all the cases I was
thinking about without any further case division.

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

Good! It certainly takes care of the one concrete breakage we know about so

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list