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

[Mark S. Miller]

On Tue, Jan 27, 2015 at 5:53 PM, Boris Zbarsky <bzbarsky at 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
far.



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150127/d5292b99/attachment.html>