Figuring out the behavior of WindowProxy in the face of non-configurable properties
Mark S. Miller
erights at google.com
Thu Dec 4 08:49:34 PST 2014
On Thu, Dec 4, 2014 at 2:58 AM, Boris Zbarsky <bzbarsky at 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 at 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
>>> a non-configurable property that got defined on the Window (e.g. via
>>> 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
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
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.
> going to try doing it in Firefox, and would welcome other UAs doing it ASAP
> to figure out whether we're in that situation.
More information about the es-discuss