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:39:31 -0800
Message-ID: <CABHxS9iuJzCkr1dAfsnzdLjeXFSBHbyhG_ZZJo7ma=GrZfUO1w@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 9:45 PM, Mark S. Miller <erights@google.com> wrote:

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

Here's another option, not clearly better or worse:

[[DefineOwnProperty]] (P, Desc)

   1. let R be the result of calling the [[DefineOwnProperty]] internal
   method of *W* with arguments *P* and *Desc*.
   2. If *desc*.[[Configurable]] is present and *false*, then throw a
   *TypeError* exception.
   3. return R.

This is exactly like your solution, but with the order of the two steps
switched. Perhaps the next breakage we see will tell us which of these to
choose. If both are web compatible, then we need only pick which one we
like better.



>
>
>
>> 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 far.
>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
Received on Wednesday, 28 January 2015 06:40:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 28 January 2015 06:40:00 UTC