-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a [[OwnPropertyKeys]] for legacy platform objects #400
Comments
Note that as per tc39/ecma262#833 we should also call it out as a specification error if we end up with duplicate entries somehow. (Maybe an Assert?) |
Sure, or we can just make it an ordered set (in Infra terminology). |
TimothyGu
added a commit
to TimothyGu/webidl
that referenced
this issue
Aug 7, 2017
TimothyGu
added a commit
to TimothyGu/webidl
that referenced
this issue
Aug 7, 2017
TimothyGu
added a commit
to TimothyGu/webidl
that referenced
this issue
Aug 7, 2017
By the way, how does this relate to #79? |
@annevk They are same issue as far as I can tell, but this one asks for a normative change while that one is more of an editorial nature. |
bzbarsky
pushed a commit
that referenced
this issue
Aug 12, 2017
* Define [[OwnPropertyKeys]] of legacy platform objects Fixes #400. * fixup! update blurb per Tobie
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the following JS snippet:
On Chrome this emits:
while on Firefox it shows:
Though it is not defined as an invariant in ECMAScript, it would still seem a good idea to bring Firefox's behavior into the standard, as one would expect an own property according to
hasOwnProperty
to be in theownKeys
of that object.Web IDL does already define property enumeration orders for enumerable properties, but this specific issue concerns all keys, not only those that are enumerable. And the way to specify that is by imperatively defining an [[OwnPropertyKeys]] internal method, like ES's built-in OrdinaryOwnPropertyKeys abstract op.
FWIW, both Chrome and Firefox's
Object.keys
return the correct properties according to the spec.element.attributes
's typeNamedNodeMap
is defined with [LegacyUnenumerableNamedProperties
], so none of those named properties are enumerable.The text was updated successfully, but these errors were encountered: