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: Wed, 14 Jan 2015 22:14:05 -0800
Message-ID: <CABHxS9johfAD69eOfm7g==kFQcRMYCsyyHLGuH=QRBZckf6f3w@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>
Thanks. It is great to accumulate such retreats in case we need them.
However, it is also good to remember that, should we run into problems,
that experience will give us specific data that we might not have been able
to anticipate. The least painful retreat may very well take that specific
data into account.

The case of Object.prototype.toString.call(null) was an informative
precedent.



On Wed, Jan 14, 2015 at 9:50 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 12/4/14 5:58 AM, Boris Zbarsky wrote:
>
>> OK.  What do we do if we discover that throwing from the defineProperty
>> call with a non-configurable property descriptor is not web-compatible?
>>
>
> Based on a nice long conversation Yehuda and I just had, if we end up
> there and really want to preserve all the current invariants we could try a
> hybrid approach inspided by the Safari implementation.  To whit:
>
> 1)  Assume that we can distinguish when we're "inside" a window and when
> we're "outside" it.  For example, compare the current Realm's global to the
> window.
>
> 2)  When inside the window, everything works as normal: you can define a
> non-configurable property on the window you're inside,
> getOwnPropertyDescriptor will claim it's non-configurable, etc.  At least
> while that window is current.  Once it's non-current, I haven't tested what
> Safari does and am not sure what we could/should spec.
>
> 3)  When outside the window, where observing navigations is easy, we try
> to apply one of the possible mitigations: throw on defineProperty that's
> non-configurable or whatnot, report all props as configurable, etc. This
> seems to be all kosher if we assume a membrane between inside and outside
> the window, such that we're actually operating on different objects in the
> two cases...
>
> This may mitigate the compat impact depending on what compat issues we run
> into.
>
> Just wanted to get this written down while it's fresh in my mind,
> Boris
>



-- 
    Cheers,
    --MarkM
Received on Thursday, 15 January 2015 06:14:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 January 2015 06:14:35 UTC