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

On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 11/30/14, 6:12 PM, Mark S. Miller wrote:
>>
>> On Sun, Nov 30, 2014 at 12:21 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>>
>>> Per spec ES6, it seems to me like attempting to define a non-configurable
>>> property on a WindowProxy should throw and getting a property descriptor
>>> for
>>> a non-configurable property that got defined on the Window (e.g. via
>>> "var")
>>> should report it as configurable.
>>
>>
>> Yes, both of these conclusions are correct.
>
>
> OK.  What do we do if we discover that throwing from the defineProperty call
> with a non-configurable property descriptor is not web-compatible?

What we always do, for example, when we found that having

     Object.prototype.toString.call(null)

throw was not web compatible. We look into the specifics of the
incompatibility encountered and design a non-web-breaking workaround
that is least painful for the semantics we desire. For example, in
this case, we changed it to return
"[object Null]" even though that string itself had never previously
been returned. The specific web compatibility we encountered for this
case merely required a non-throw. It did not care what the contents of
the string were. This outcome could not have been predicted from first
principles.

Other times, as when we found that introducing a new global variable
named "JSON" was not web compatible, we found we could evangelize the
origin of that incompatibility to fix it at the source, rather than
change the spec.


>  I'm
> going to try doing it in Firefox, and would welcome other UAs doing it ASAP
> to figure out whether we're in that situation.

Excellent! Bravo!


>
> -Boris



-- 
    Cheers,
    --MarkM

Received on Thursday, 4 December 2014 16:50:01 UTC