W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2014

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

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Thu, 4 Dec 2014 18:44:13 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>, "Mark S. Miller" <erights@google.com>
CC: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
Message-ID: <BL2PR03MB1136299794ABA03C2232A33F8780@BL2PR03MB113.namprd03.prod.outlook.com>
So... this will prevent defining non-configurable properties on the global? Combined with [PrimaryGlobal], this seems at odds with what browsers do internally to prevent re-definition of some properties like "document"? Are we sure we want this restriction?

> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@mit.edu]
> Sent: Thursday, December 4, 2014 2:59 AM
> To: Mark S. Miller
> Cc: es-discuss; public-script-coord@w3.org; Domenic Denicola
> Subject: Re: Figuring out the behavior of WindowProxy in the face of non-
> configurable properties
> 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?
>   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.
> -Boris

Received on Thursday, 4 December 2014 18:44:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC