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 21:45:29 -0800
Message-ID: <CABHxS9jwDo3KoYr2fCXazkhf17Q7sH1jZ5tjpheMEaj3kd=g=g@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky <bzbarsky@mit.edu> 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 <https://github.com/domenic/
> 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

Received on Wednesday, 28 January 2015 05:45:56 UTC

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