Should the Window named properties object return supported named properties in [[OwnPropertyKeys]]?

[delan]

Given data:text/html,<iframe name=123> with Reflect.ownKeys(window.__proto__.__proto__)…

• Gecko returns ["123", Symbol(Symbol.toStringTag)]
• Blink returns [Symbol(Symbol.toStringTag)]
• WebKit returns [Symbol(Symbol.toStringTag)]

This seems to be why Firefox fails the [[OwnPropertyKeys]] subtest of /webidl/ecmascript-binding/window-named-properties-object.html, but I can’t figure out what the correct behaviour is according to the spec. This is how far I got:

• WindowProxy (the wrapper with indexed access) has an exotic [[OwnPropertyKeys]]
• “This document does not define a complete property enumeration order for platform objects implementing interfaces (or for platform objects representing exceptions). However, it does for legacy platform objects by defining the [[OwnPropertyKeys]] internal method as follows.”
  • so legacy platform objects have an exotic [[OwnPropertyKeys]] that includes supported property names (subject to named property visibility), but for other platform objects the behaviour of [[OwnPropertyKeys]] is undefined?
• Window itself (the interface with named access) is [Global], so Window objects are not legacy platform objects

Have I missed something? Does this mean both Gecko and Blink and WebKit are correct?

(cc @domenic, on behalf of servo/servo#29396)

[domenic]

web-platform-tests/wpt#36746 was recently opened and seems related.

• but for other platform objects the behaviour of [[OwnPropertyKeys]] is undefined?

No, just the order. The behavior is given by the ordinary non-exotic [[OwnPropertyKeys]], for which ES262 says is "in ascending chronological order of property creation". So the quoted part of Web IDL is saying that the exact order in which properties are created for platform objects is not defined.

I guess this is somewhat of a lie, because https://webidl.spec.whatwg.org/#interface-prototype-object step 11-12 has a sort of order: attributes, operations, iteration methods, async iteration methods, constants. But within those categories ordering is not defined. And this ordering is unintentional and wasn't thought through. whatwg/webidl#432 is the canonical issue for discussing this.

Have I missed something? Does this mean both Gecko and Blink and WebKit are correct?

No. Blink and WebKit are correct. The named properties object uses OrdinaryOwnPropertyKeys, which iterates over the property keys of the object. But there are no property keys of the named properties object; instead it has custom behavior in its [[GetOwnProperty]] handler. web-platform-tests/wpt#36746 discusses this in detail.

[delan]

Thanks! Do you think it would be helpful if I added a note clarifying that named properties objects don’t have any real properties, so its ordinary [[OwnPropertyKeys]] won’t return any supported named properties, and a note clarifying that Window’s named properties use the rules for named properties objects rather than legacy platform objects?

[domenic]

I added a note clarifying that named properties objects don’t have any real properties, so its ordinary [[OwnPropertyKeys]] won’t return any supported named properties,

Yes, I think that'd definitely be helpful.

a note clarifying that Window’s named properties use the rules for named properties objects rather than legacy platform objects?

Yeah, adding something like that around https://html.spec.whatwg.org/multipage/nav-history-apis.html#named-access-on-the-window-object would make sense to me.

[delan]

Done in #9080 and whatwg/webidl#1285 :)