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

Mark S. Miller erights at
Wed Jan 28 11:16:06 PST 2015

On Wed, Jan 28, 2015 at 11:08 AM, Domenic Denicola <d at> wrote:

> From: Mark S. Miller [mailto:erights at]
> > In this situation, it will try and succeed. This more closely obeys the
> intent in the original code (e.g., the comment in the jQuery code), since
> it creates a non-configurable property on the *Window* W. It does not
> violate any invariant, since all that's observable on the *WindowProxy*
> (given the rest of your draft spec, which remain unchanged) is a
> configurable property of the same name.
> Ah, I see! So then another non-intuitive (but invariant-preserving)
> consequence would be:
> ```js
> Object.defineProperty(window, "prop", { value: "foo" });
> var propDesc = Object.getOwnPropertyDescriptor(window, "prop");
> if (propDesc.configurable) {
>   Object.defineProperty(window, "prop", { value: "bar" });
>   // this will fail, even though the property is supposedly configurable,
>   // since when it forwards from the WindowProxy `window` to the underlying
>   // Window object, it the Window's [[DefineOwnProperty]] fails.
> }
> ```
> Am I getting this right?

Exactly, yes. And again, if window is an ES6 proxy rather that a
WindowProxy, it could also cause this behavior, so it doesn't create any
situation which is not otherwise possible.

The key points are:

1) The throw does (arguably) better obey the code's intent, since the
property mostly acts like a non-configurable property until the window is

2) If a window navigation happens between your first step and your second,
the second step may well succeed, which is what we (arguably) want, but
which would have been prohibited if propDesc.configurable evaluated to true.

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

More information about the es-discuss mailing list