[whatwg] [[GetOwnProperty]] for named properties of the Window object
Hi, I was wondering if anyone could help clarify expected behavior of [[GetOwnProperty]] for named properties of the Window object. (It looks like this falls across the HTML5 & WebIDL specs, apologies if this is the wrong place to ask). Per WebIDL’s definition of [Global] (http://dev.w3.org/2006/webapi/WebIDL/#Global) the named properties are exposed on a named properties object on the prototype chain. Per section 4.5.5.1 (http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object) the [[GetOwnProperty]] implementation should return a descriptor with writable set to false, enumerable and configurable set to true. Firefox and Chrome both return descriptors from an object on the prototype chain per the spec, attributes of the value are configured differently, with enumerable set to false, writable and configurable set to true. There seem to be some compelling reasons to follow Firefox / Chrome (writable true seems more congruent with ECMA262 specified [[Put]], unless there is another mechanism I’m missing here, enumerable is odd since I don’t think the spec says anything about [[GetOwnPropertyNames]]),so I was hoping to better understand why the spec requires the behaviour it does (or whether I’m just following it incorrectly!) Many thanks, Gavin
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
Ccing public-script-coord, since that's the right place for this
discussion (because WebIDL is the relevant specification).
On 9/5/13 6:45 PM, Gavin Barraclough wrote:
Firefox and Chrome both return descriptors from an object on the prototype
chain per the spec
Chrome doesn't quite follow the spec here, for what it's worth: it
returns them from Window.prototype as far as I can tell, not from an
actual named properties object.
attributes of the value are configured differently, with enumerable set to
false, writable and configurable set to true.
Current tip Firefox returns
{"configurable":true,"enumerable":true,"writable":true} and enumerates
the properties. Probably a change from
https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with
the spec in terms of the enumeration behavior.
There seem to be some compelling reasons to follow Firefox / Chrome (writable
true seems more congruent with ECMA262 specified [[Put]]
Indeed. I think the current setup in the spec would make window.foo not
settable if exists That seems bad.
unless there is another mechanism I’m missing here, enumerable is odd since I
don’t think the spec says anything about [[GetOwnPropertyNames]])
It doesn't, but it does talk about enumeration; see
http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether
that's applicable to the Named Properties Object is an interesting
question).
Granted, I would rather that were defined in terms of
[[GetOwnPropertyNames]] on the relevant objects instead; that's what
actually needs to happen under the hood anyway.
,so I was hoping to better understand why the spec requires the behaviour it
does (or whether I’m just following it incorrectly!)
I think you're following it correctly; it's just buggy. ;)
-Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
Hi Boris,
Thanks, this is really helpful.
On Sep 5, 2013, at 7:15 PM, Boris Zbarsky wrote:
> Ccing public-script-coord, since that's the right place for this discussion
> (because WebIDL is the relevant specification).
>
> On 9/5/13 6:45 PM, Gavin Barraclough wrote:
>> Firefox and Chrome both return descriptors from an object on the prototype
>> chain per the spec
>
> Chrome doesn't quite follow the spec here, for what it's worth: it returns
> them from Window.prototype as far as I can tell, not from an actual named
> properties object.
Interesting, I had just assumed this was okay – is it not spec-compliant for
Window.prototype to be a named properties object?
>> attributes of the value are configured differently, with enumerable set to
>> false, writable and configurable set to true.
>
> Current tip Firefox returns
> {"configurable":true,"enumerable":true,"writable":true} and enumerates the
> properties. Probably a change from
> https://bugzilla.mozilla.org/show_bug.cgi?id=895758 to align better with the
> spec in terms of the enumeration behavior.
>
>> There seem to be some compelling reasons to follow Firefox / Chrome
>> (writable true seems more congruent with ECMA262 specified [[Put]]
>
> Indeed. I think the current setup in the spec would make window.foo not
> settable if exists That seems bad.
I believe these properties are implemented as shadowable in the same way as
[Replaceable] properties, so I was somewhat expecting the spec to define
properties returned by named property objects to implicitly have the
[Replaceable] extended attribute specified in WebIDL (and then assume a
modified behaviour of ES [Put] for properties with this attribute, to permit
overwrite even if readonly). But I’m not yet familiar enough with the spec to
know if this is a reasonable line of thought. :-)
Thanks,
Gavin
>> unless there is another mechanism I’m missing here, enumerable is odd since
>> I don’t think the spec says anything about [[GetOwnPropertyNames]])
>
> It doesn't, but it does talk about enumeration; see
> http://dev.w3.org/2006/webapi/WebIDL/#property-enumeration (whether that's
> applicable to the Named Properties Object is an interesting question).
>
> Granted, I would rather that were defined in terms of [[GetOwnPropertyNames]]
> on the relevant objects instead; that's what actually needs to happen under
> the hood anyway.
>
>> ,so I was hoping to better understand why the spec requires the behaviour it
>> does (or whether I’m just following it incorrectly!)
>
> I think you're following it correctly; it's just buggy. ;)
>
> -Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On 9/11/13 6:05 PM, Gavin Barraclough wrote: Interesting, I had just assumed this was okay – is it not spec-compliant for Window.prototype to be a named properties object? No, it's not. The spec defines exactly what the prototype chain looks like here. See the definitions of [[Prototype]] at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at the latter). So the chain by default is window -> Window.prototype -> named properties object -> EventTarget.prototype -> Object.prototype. This allows specification of the named properties object without having to worry about weird interactions with name collisions on Window.prototype, whether with properties it has by default or properties someone wants to add to it. Note that the named properties object does not allow [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be able to add any properties to Window.prototype! I believe these properties are implemented as shadowable in the same way as [Replaceable] properties [Replaceable] properties need the magic they have because they're accessor properties, which normally can't be shadowed via assignment. But named properties on the named properties object are value properties, so simply making them writable allows them to be shadowed. In fact, that's the only way to make them shadowable. (and then assume a modified behaviour of ES [Put] for properties with this attribute, to permit overwrite even if readonly). I don't think a special [Put] is needed if the properties aren't readonly. -Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On Sep 11, 2013, at 6:07 PM, Boris Zbarsky wrote: > On 9/11/13 6:05 PM, Gavin Barraclough wrote: >> Interesting, I had just assumed this was okay – is it not spec-compliant for >> Window.prototype to be a named properties object? > > No, it's not. The spec defines exactly what the prototype chain looks like > here. See the definitions of [[Prototype]] > athttp://dev.w3.org/2006/webapi/WebIDL/#named-properties-object and > http://dev.w3.org/2006/webapi/WebIDL/#interface-prototype-object (item 1 at > the latter). Ah, got it, thanks. I’d only spotted the partial description in http://dev.w3.org/2006/webapi/WebIDL/#Global > So the chain by default is window -> Window.prototype -> named properties > object -> EventTarget.prototype -> Object.prototype. > > This allows specification of the named properties object without having to > worry about weird interactions with name collisions on Window.prototype, > whether with properties it has by default or properties someone wants to add > to it. Note that the named properties object does not allow > [[DefineOwnProperty]], so if it were Window.prototype then you wouldn't be > able to add any properties to Window.prototype! > >> I believe these properties are implemented as shadowable in the same way as >> [Replaceable] properties > > [Replaceable] properties need the magic they have because they're accessor > properties, which normally can't be shadowed via assignment. > > But named properties on the named properties object are value properties, so > simply making them writable allows them to be shadowed. In fact, that's the > only way to make them shadowable. Got it. >> (and then assume a modified behaviour of ES [Put] for properties with this >> attribute, to permit overwrite even if readonly). > > I don't think a special [Put] is needed if the properties aren't readonly. Hmmm, interesting. I was thinking that in the case that a shadowing property was put to the named property object itself, then deleted, this needed further description (as the old property reappears) – but I guess that it just covered by the current spec [[GetOwnProperty]] implementation. Many thanks, Gavin
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On Sep 12, 2013, at 11:43 AM, Boris Zbarsky wrote: > On 9/12/13 2:36 PM, Gavin Barraclough wrote: >> Hmmm, interesting. I was thinking that in the case that a shadowing >> property was put to the named property object itself > > Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor > here, so we land in step 3b, which calls [[DefineOwnProperty]], which is > defined at > http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownpropertyand > throws if "Throw" and silently does nothing otherwise. ES6 is similar. Ah, good point. Firefox, Safari, Chrome all currently all allow this, but seems reasonable to prohibit. cheers, G. >> then deleted > > Also can't be done. See > http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete > >> Many thanks, > > No problem! > > -Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On 9/12/13 2:36 PM, Gavin Barraclough wrote: Hmmm, interesting. I was thinking that in the case that a shadowing property was put to the named property object itself Can't be done. Looking at the ES5 [[Put]], ownDesc is a data descriptor here, so we land in step 3b, which calls [[DefineOwnProperty]], which is defined at http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-defineownproperty and throws if "Throw" and silently does nothing otherwise. ES6 is similar. then deleted Also can't be done. See http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object-delete Many thanks, No problem! -Boris
Re: [whatwg] [[GetOwnProperty]] for named properties of the Window object
On 9/12/13 4:50 PM, Gavin Barraclough wrote: Ah, good point. Firefox, Safari, Chrome all currently all allow this, but seems reasonable to prohibit. For what it's worth, Firefox nightlies prohibit it, ever since https://bugzilla.mozilla.org/show_bug.cgi?id=895758 allowed us to actually do so. -Boris
