Define a [[OwnPropertyKeys]] for legacy platform objects

[TimothyGu]

Consider the following JS snippet:

(() => {
  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:

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

while on Firefox it shows:

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

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 the ownKeys 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 type NamedNodeMap is defined with [LegacyUnenumerableNamedProperties], so none of those named properties are enumerable.

[annevk]

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?)

[TimothyGu]

Sure, or we can just make it an ordered set (in Infra terminology).

[annevk]

By the way, how does this relate to #79?

[TimothyGu]

@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.