[heycam/webidl] Define a [[OwnPropertyKeys]] for legacy platform objects (#400)

Consider the following JS snippet:

```js
(() => {
  const element = document.createElement("div");
  element.setAttribute("length", "len_val");
  element.setAttribute("unrestricted", "unr_val");
  element.attributes.ownProp = 'own prop';
  console.log(Reflect.ownKeys(element.attributes));
  console.log(Object.keys(element.attributes));
  console.log(element.attributes.hasOwnProperty("unrestricted"));
  console.log(element.attributes.unrestricted);
})();
```

On Chrome this emits:

```js
["0", "1", "ownProp"]
["0", "1", "ownProp"]
true
unrestricted=​"unr_val"
```

while on Firefox it shows:

```js
[ "0", "1", "unrestricted", "ownProp" ]
[ "0", "1", "ownProp" ]
true 
unrestricted="unr_val"
```

Though it is not defined as an [invariant](https://tc39.github.io/ecma262/#sec-invariants-of-the-essential-internal-methods) 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 the `ownKeys` of that object.

Web IDL does already define [property enumeration](https://heycam.github.io/webidl/#legacy-platform-object-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](https://tc39.github.io/ecma262/#sec-ordinaryownpropertykeys) abstract op.

FWIW, both Chrome and Firefox's `Object.keys` return the correct properties according to the spec. `element.attributes`'s type `NamedNodeMap` is defined with [`LegacyUnenumerableNamedProperties`], so none of those named properties are enumerable.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/400

Received on Friday, 4 August 2017 11:30:02 UTC