Normative: Match ECMA‑262 function property enumeration order

[ExE-Boss]

This makes the order of the "length", "name" and "prototype" properties on WebIDL function objects match web reality (at least Firefox’s behaviour) and ECMA‑262 as of tc39/ecma262#1490 and tc39/ecma262#2116, which also changed CreateBuiltinFunction so that it takes the additional length and name required parameters.

---

• At least two implementers are interested (and none opposed):
  • Firefox (already implements this)
  • Safari (implemented as of changeset 280289)
• Tests are written and can be reviewed and commented upon at:
  • [WebIDL] Add tests for function property enumeration order web-platform-tests/wpt#30333
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1257969
  • Firefox: N/A
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=230584 (FIXED)

(See WHATWG Working Mode: Changes for more details.)

---

review?(@annevk, @domenic, @littledan, @ljharb)

Fixes #1106

---

Preview | Diff

[ExE-Boss]

tc39/ecma262#2116 has been merged, so this PR has been updated to pass the length and name parameters to CreateBuiltinFunction directly.

[annevk]

Great work @ExE-Boss! I'll leave this to others to review, but this looks like a really nice cleanup. Do we have some tests for this as well?

[Ms2ger]

Looks good as far as the spec goes, but each of these calls needs to be tested. The values are probably mostly covered by idlharness, but the order of iteration probably isn't.

[TimothyGu]

Looks pretty good.

Just wondering @ExE-Boss, have you had any progress on writing tests for this PR?

[TimothyGu]

For readability, may I suggest a tabular format like this:

6. For each row in the following table:

   Name	Section	Length
   "defineProperty"	§ 3.10.1 defineProperty	3
   "deleteProperty"	§ 3.10.2 deleteProperty	2
   …	…	…

   1. Let (name, section, length) be the entries of the current row.
   2. Let F be ! CreateBuiltinFunction(the steps from section, length, name, « », realm).
   3. Perform ! CreateDataProperty(handler, name, F).

This helps make length changes more visible to implementors and folks writing tests, and also seems to be generally more readable.

[TimothyGu]

@domenic could you take a look at this part of the PR if have some time?

[domenic]

Hmm. I kind of like the way the PR currently does it for lengths, in that it doesn't require syncing the length column with the steps like your proposal would.

Since the proxy handlers are an unobservable internal implementation detail anyway, I think we could just set the length to 0 and the name to "" for all of them, with a <p class="note"> explaining?

The table/loop format would improve the section in general, but I'm not sure it needs to be done in this PR.

[domenic]

@TimothyGu should we merge as-is? Or go for the 0/"" solution maybe?

[ExE-Boss]

Tests are now written in web-platform-tests/wpt#30333.

[domenic]

Based on web-platform-tests/wpt#30333 it looks like this matches Firefox but mismatches Chrome and Safari (for constructors). So we should make sure at least one of those browsers is interested in changing. @yuki3 @shvaikalesh what do you think?

[bakkot]

Reflect.ownKeys(Blob):

• Chrome: ["length", "name", "arguments", "caller", "prototype"]
• Firefox: [ "length", "name", "prototype", Symbol("Symbol.hasInstance") ]
• Safari: ["prototype", "name", "length"]

So, Chrome has additional arguments and caller properties, which surprises me. (They appear to be non-functional, at least - (function f(){ new Blob([], { get type(){ console.log(Blob.caller, Blob.arguments) } }) })() prints null twice.)

But Chrome does match the enumeration order for the length and name properties, which I think is the only change actually implied by this PR. In particular, ecma262 specifically refrains from specifying the full enumeration order, including of prototype; it only specifies that length appears before name. (The test262 tests for the corresponding ecma262 PR are much more permissive than the WPT linked above.)

So, possibly the WPT is just over-zealous for the actual change implied by this PR, and could be changed to match the test262 tests. Then both Chrome and Firefox would pass.

[domenic]

@bakkot to check my understanding, it seems like the correct test would be that name appears right after length, right? So the test262 test is not as fully strict as it could be.

I think Web IDL, being more imperative than the ES spec, actually gives a full ordering between length/name/prototype that matches the tests written. But in terms of ensuring implementer interest for this particular change, I agree we're probably OK.

[ExE-Boss]

it seems like the correct test would be that name appears right after length, right? So the test262 test is not as fully strict as it could be.

Actually, the test262 test checks exactly that using: nameIndex === lengthIndex + 1

assert(lengthIndex >= 0 && nameIndex === lengthIndex + 1,
	"The `length` property comes before the `name` property on built-in functions");

[domenic]

Sorry, I totally skimmed the test and misread it. My bad.

[ExE-Boss]

@bakkot

So, possibly the WPT is just over-zealous for the actual change implied by this PR, and could be changed to match the test262 tests. Then both Chrome and Firefox would pass.

With this PR, the prototype property is the first property that’s added to constructors after the CreateBuiltinFunction call in create an interface object.

[bakkot]

it seems like the correct test would be that name appears right after length, right?

Right.

I think Web IDL, being more imperative than the ES spec, actually gives a full ordering between length/name/prototype that matches the tests written.

Ah, so it does.

[shvaikalesh]

I like this change, both editorial-wise and the way it improves enumeration order consistency. Please use this bug to follow WebKit implementation.

As for caller and arguments, there is a proposal to move them to Function.prototype, which was recently implemented in WebKit to match Firefox.

[yuki3]

Based on web-platform-tests/wpt#30333 it looks like this matches Firefox but mismatches Chrome and Safari (for constructors). So we should make sure at least one of those browsers is interested in changing. @yuki3 @shvaikalesh what do you think?

I'm very sorry that I somehow overlooked the mention. I'm fine with the change to make the order of property enumeration consistent. However, I'm afraid that I cannot help much on this. IIUC, the order of these standard(ish?) properties on function objects is controlled by V8. We'd better ask V8 team to make the change. @verwaest, any thoughts?

[verwaest]

The proposed changes sound alright. Making this more uniform makes sense.

It seems like we're invalidly adding special accessors for caller/arguments but will always return null for native functions. We can change that too.

As for moving caller/arguments to the prototype chain: Currently v8 returns the caller of the "holder" on which the property is installed. With this I mean that if you put a function with a .caller on the prototype chain of e.g., a sloppy-mode arrow function, we won't return the caller of the arrow function, but the caller of the function on the prototype chain. What are the expected semantics there? (The change itself sounds like an improvement though!)

[shvaikalesh]

@verwaest The proposal sets up Function.prototype.{arguments,caller} as getters (spec), so they can return null or real caller or even throw a TypeError depending on a holder (receiver).

One important bit of the proposal I kinda hope V8 would implement is returning null for (async) generators to match the JSC: we can't return real caller for them and it seems web-compatible.

[ExE-Boss]

I’ve filed bug 1257969 to get this fixed in Chrome as well.

[ExE-Boss]

The “needs tests” label is wrong, as web-platform-tests/wpt#30333 has been merged.

[Ms2ger]

Argh, apologies for merging the tests ahead of time. Would be good to get this landed anyway, though.

[annevk]

That's blocked on one of two things:

1. @ExE-Boss updates https://github.com/whatwg/participant-data/blob/main/individuals.json with their real name. (See Can contributors use pseudonyms to sign the participation agreement? sg#93 (comment) for context.)
2. Someone else makes this contribution in a new PR.