[whatwg] [[GetOwnProperty]] for named properties of the Window object
Boris Zbarsky
bzbarsky at MIT.EDU
Thu Sep 5 19:15:34 PDT 2013
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 <img id="foo"> 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
More information about the whatwg
mailing list