W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

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

From: Mark S. Miller <erights@google.com>
Date: Tue, 27 Jan 2015 22:02:49 -0800
Message-ID: <CABHxS9h6ndysah9mNeyt4sdfFpwcHd+8irJoUJXiyanV1xB4Bg@mail.gmail.com>
To: Brendan Eich <brendan@mozilla.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Domenic Denicola <domenic@domenicdenicola.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Tue, Jan 27, 2015 at 7:22 PM, Brendan Eich <brendan@mozilla.org> wrote:

> Mark S. Miller wrote:
>> The reason why the intent is unwarranted is that the descriptor omits
>> "configurable:" rather than explicitly saying "configurable: true". If the
>> owner object already has a configurable own property of the same name, then
>> a defineProperty where the "configurable:" is omitted defines an own
>> property preserving the configurability of the original own property.
> Wild, and genius.


> How many more narrow escapes can we make and keep both web compat and
> integrity? :-P

How many will we need? ;)

> Is there any downside? What is the bad case that observably changes
> behavior, if any (not involving proxies)?

You get the following non-intuitive but allowed behavior.

if (!hasOwnProperty(W, P)) {
  defineProperty(W, P, { value: V })
  console.log(getOwnPropertyDescriptor(W, P).configurable); // true

However, you could also get this behavior if W is a proxy, so it doesn't
introduce any new cases beyond what's already possible. It is only

That's not much of a downside, and I can't think of any other downside.

I'm too tired to search the state space right now, throwing this out as a
> challenge.

Received on Wednesday, 28 January 2015 06:03:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC