Define [[OwnPropertyKeys]] of legacy platform objects

[TimothyGu]

Fixes #400.

---

Preview | Diff

[tobie]

Thanks a lot for making this. Overall this looks really solid! Couple of comments and questions below (this is a part of the spec I'm not super familiar with, so please bear with me if some of those are silly).

[tobie]

Why not used an ordered list instead (as you initially suggested)?

[TimothyGu]

(Assuming you meant ordered set...) ES uses a plain List, and it would actually be a specification error if there are duplicates, since the named property visibility algorithm should filter out any supported property names that are also own properties on the object (or in its prototype chain).

[tobie]

(Assuming you meant ordered set...)

I did. :)

ES uses a plain List, and it would actually be a specification error if there are duplicates, since the named property visibility algorithm should filter out any supported property names that are also own properties on the object (or in its prototype chain).

That makes sense.

[tobie]

The effects of the [{{LegacyUnenumerableNamedProperties}}] extended attribute seem totally gone from the updated algorithm. Is that on purpose?

[TimothyGu]

Yes, LegacyUnenumerableNamedProperties controls the enumerable bit in the descriptor but not the existence of the key. See [[GetOwnProperty]]. The original pseudo-algorithm defines the "enumeration order", basically the order of for-in loops, which accounts for both enumerability and key existence.

[tobie]

Are these also in ascending chronological order?

[TimothyGu]

The order is defined by the specification for the specific interface.

[tobie]

Oh, right. That's the order in which they're spec'ed. In one of the toJSON-related algorithms we write this as:

If a toJSON operation with a [Default] extended attribute is declared on |I|,
then for each exposed regular attribute |attr| that is an interface member of |I|,
in order:

Maybe just add in order, before [=list|append=] |P| to |keys|?

[annevk]

"for each" from Infra already defines the order so you don't have to add that kind of thing. (At least, iirc that's the idea.)

[tobie]

@annevk, you're right. I'd just like to be a little more explicit in both those cases that enumeration order follows the order in which the attributes are specified in the interface. But we can leave that out for now and fix them up both together later if necessary.

[tobie]

I totally mixed up a bunch of things here. Apologies for muddling the conversation. Please ignore this comment altogether.

[tobie]

Would be great to add a small blurb here that this is done by the [[OwnPropertyKeys]] method, e.g:

This document does not define a complete property enumeration order
for [=platform objects=] implementing [=interfaces=]
(or for <a href="#es-exception-objects">platform objects representing exceptions</a>).
However, it does for [=legacy platform objects=] by defining the \[[OwnPropertyKeys]] method as follows:

[TimothyGu]

I seem to have forgotten to update that blurb… will do.

[domenic]

First of all, this PR is awesome.

Second, I am concerned about the extent to which it matches implementations, especially with regard to ordering. In particular, it's possible implementations don't have a good order except in enumeration cases, if they don't map onto the recent ES spec updates which derive enumeration from own property keys.

So, we'll need some good tests of the various permutations here to be sure.

[tobie]

So, we'll need some good tests of the various permutations here to be sure.

@domenic how do you want to go about this? Land this, then add the tests, then given the test results, file issues with rendering engines? Or do you want to wait until we have test results before we land this?

[TimothyGu]

I am concerned about the extent to which it matches implementations, especially with regard to ordering

While I did write this PR to match what implementations are doing, I would agree that there are a lot of corner cases, like index prop names that are not array index prop names ([2^32, 2^53)), assigning array index prop names to objects that don't support indexed properties (and vice versa), and symbols. To that end I'd definitely agree that there should be tests.

if they don't map onto the recent ES spec updates which derive enumeration from own property keys

Can you point out the update you are referring to?

So, we'll need some good tests of the various permutations here to be sure.

Is there a specific section in WPT for Web IDL compliance or should I look into adding these tests to the section of the tested interface (e.g. HTMLCollection)?

[domenic]

While I did write this PR to match what implementations are doing

Ah OK, that's great. I thought it might have been just a translation of the previous enumeration section, in which case there was more cause for concern. But if you have validated this roughly matches browsers, then I would be comfortable merging before in-depth tests. @tobie

Can you point out the update you are referring to?

tc39/ecma262#367

Is there a specific section in WPT for Web IDL compliance or should I look into adding these tests to the section of the tested interface (e.g. HTMLCollection)?

https://github.com/w3c/web-platform-tests/tree/master/WebIDL, almost always under ecmascript-binding. As you can see from some tests there, we generally pick representative objects. https://github.com/w3c/web-platform-tests/blob/255d54144a82ce76d8e50a4aa8de284151119f8b/WebIDL/ecmascript-binding/legacy-platform-object.html is probably the file to work on, although I think nobody would mind having a separate file for the OwnPropertyKeys sub-cases as that file is so generically named it could grow without bound.

[TimothyGu]

I've completed a more comprehensive audit of what browsers currently do. And the results are, well, inconsistently inconsistent. The test is live at https://timothygu.me/webidl-keys-test/, and the files available in https://github.com/TimothyGu/webidl-keys-test.

I specifically looked at three interfaces: NamedNodeMap (used for element.attributes), NodeList (through node.childNodes), and Storage (through window.sessionStorage). For browsers, I checked Chrome 60 (stable) and 61 (beta), Firefox 55 beta, and Edge 15. I couldn't get used to Safari's developer console, but at a glance its behavior is fairly similar to Chrome's.

---

From results from NamedNodeMap and NodeList:

Chrome and Edge both exhibit the original issue I opened #400 for, namely they do not include named properties on an interface annotated with [LegacyUnenumerableNamedProperties] in Reflect.ownKeys(), while Firefox does. This PR follows the Firefox behavior, as IMO [LegacyUnenumerableNamedProperties] should only set the enumerable bit rather than hide it from getting all property names. I'm open for some discussion around this however, since it's 1 vs. 2.

While Chrome and Firefox (and this proposal) consistently put own property symbols at the end for legacy platform objects in the same way as ES operates, Edge puts symbols in the front of all own properties.

Not directly related to this proposal, Chrome 60 and Edge follow the current [[Set]] semantics in that for interfaces not supporting indexed properties, it still sets any indexed properties as own properties. However, Chrome 61 and Firefox will throw when trying to do so.

Also not directly related to this proposal, Edge has a bug where its Reflect.ownKeys() returns duplicated property names when an object has both an own property and a supported indexed property link. In that situation, when getting the duplicated key it gets the own property instead. Chrome 60 does it correctly, but the enumeration order is a bit off. Chrome 61 and Firefox did not get to this test because it threw an error when trying to set the own property earlier.

---

As for Storage, all hell broke loose. No pairs of browsers do the same, and no browsers implement the spec for [[Set]]. It does reveal an issue in [[Set]] that we can fix fairly easily, but other than that there is no agreement. It also reveals browsers have subtly different [[Set]] semantics re. forbidden property names (prototype method shadowing) and symbol properties. As such, it's impossible to properly derive a pattern for enumeration from the Storage interface we can reference in [[OwnPropertyKeys]].

---

From the results, I see an even stronger need for standardization around [[OwnPropertyKeys]]. Other than [LegacyUnenumerableNamedProperties] behavior, I don't see anything that should be changed in this PR.

[bzbarsky]

The comments in the Storage test don't quite make sense to me. [[Set]] there should land in https://heycam.github.io/webidl/#legacy-platform-object-set which will call the named setter regardless of what the named property algorithm says (this is purposeful, fwiw). It will not add a normal own property. What it will do is add a thing named "getItem" to the storage. But getting the list of own properties will check the visibility algorithm and nor claim a "getItem" property.

Hence typeof sessionStorage.getItem should be "function", Reflect.ownKeys(sessionStorage) should not include "getItem", etc.

The bit about whether an index should be treated as a name for Storage seems to be #366 which has stalled for some reason. :(

I agree compat around that stuff is poor.

[TimothyGu]

@bzbarsky Thanks! I've updated the comments in the file, and it does make things clearer. To summarize, for Storage:

• Firefox and Edge's setters incorrectly ignore symbols
• Chrome's getter incorrectly gets the shadowed prototype property even when it should not be visible
• Edge's getter correctly handles shadowed properties, but still makes them visible through Reflect.ownKeys().
• Chrome enumerates symbols in chronological order instead of last.
• Chrome and Firefox put integer index properties first, even when it is really a named property and should be enumerated chronologically. Within integer index properties, Chrome then sorts them numerically. Firefox sorts them chronologically.

Do you have any comments regarding this PR itself though?

[tobie]

So we avoid doing duplicate work, heads-up that I've started refactoring legacy-platform-object.html and turning @TimothyGu's tests into wpt in a dedicated branch.

[bzbarsky]

Firefox and Edge's setters incorrectly ignore symbols

The behavior for symbols is actually not defined right now; the spec's text for them makes no sense and isn't implementable. In particular, [[Set]] in the spec ends up calling OrdinarySet for symbols, which eventually lands in the webidl-defined [[DefineOwnProperty]], which is broken in the face of symbols; see #175. Once that issue is resolved, I'll update Firefox to whatever that resolution is.

Chrome and Firefox put integer index properties first even when it is really a named property and should be enumerated chronologically

If we're still talking about Storage, then in the case of Firefox the order is rather random. In particular, it's just iterating the keys of a non-ordered hashtable, so the precise order will depend on how the keys collided, where they landed in the hashtable, etc. As in, we just don't implement the "chronological order" bit from the spec at all.

As far as the test goes, it might also be worth checking that while sessionStorage.getItem keeps returning the function, sessionStorage.getItem("getItem") returns 42.

Do you have any comments regarding this PR itself though?

Yes, I do. It's totally awesome. ;) I was worried about duplication in the list, but the fix we did for named props not shadowing existing own props even on [OverridBuiltins] interfaces makes everything work out great.

Thank you for doing this!

[TimothyGu]

In particular, it's just iterating the keys of a non-ordered hashtable

Ah, thanks for clarifying then.

Glad I could help! ❤️