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
