Ecma262: NativeError.prototype.toString?

[bathos]

I believe that Firefox is correct and that none of these properties ought to exist:

| NativeError property | Chrome | Firefox | Safari |
|-----------------------------------------------|--------|---------|--------|
| EvalError.prototype.toString | 1 | 3 | 2 |
| RangeError.prototype.toString | 1 | 3 | 2 |
| ReferenceError.prototype.toString | 1 | 3 | 2 |
| SyntaxError.prototype.toString | 1 | 3 | 2 |
| TypeError.prototype.toString | 1 | 3 | 2 |
| URIError.prototype.toString | 1 | 3 | 2 |
| WebAssembly.CompileError.prototype.toString | 1 | 3 | 3 |
| WebAssembly.LinkError.prototype.toString | 1 | 3 | 3 |
| WebAssembly.RuntimeError.prototype.toString | 1 | 3 | 3 |

1. toString is an own data property, and its value is the same as Error.protototype.toString
2. toString is an own data property, and its value is a unique function
3. toString is not present (but is inherited from Error.prototype)

I included WebAssembly errors above because they’re defined in terms of the ‘NativeError Object Structure’ and because they’re interesting due to being outlying cases in Safari.

Probably none of these results are technically implementation errors because implementations are permitted to add additional properties. But it seems likely that these differences aren’t intentional, and they’re a fairly weird/seemingly pointless spot to diverge.

If somebody can confirm which of these aren’t correct, I’ll open issues in the appropriate places. I didn’t turn up any existing reports.

[ljharb]

The spec would say it should be 3.

Are there test262 tests that cover this at all?

As for changing it, i suspect it would be easily web compatible for the 2s to change to 3s, which would be better, but I’m slightly less confident about the 2s and 3s changing to 1s.

[devsnek]

it appears that what V8 has rn was an accident (introduced in https://github.com/v8/v8/commit/9211dee01abc9e8dee16cb0915fc9673132823af), I'll open a CL to change it and hopefully it will be accepted.

I also couldn't find any test262 tests covering this.

[ljharb]

Sounds like the first step is to make test262 tests to cover what the spec says.

[bathos]

I figured the reason there weren’t tests was that it’s not a conformance issue for these other properties to exist from 262’s perspective. That is, even though intuitively we can tell that this divergence was unlikely to have been intentional, I thought checking this was outside the scope of test262 due to

A conforming implementation of ECMAScript may provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript may provide properties not described in this specification, and values for those properties, for objects that are described in this specification.

[ljharb]

I think that's technically true, but i don't personally think this divergence is in the spirit of that loophope.

[mathiasbynens]

cc @schuay re: https://github.com/v8/v8/commit/9211dee01abc9e8dee16cb0915fc9673132823af

[devsnek]

@mathiasbynens fyi https://chromium-review.googlesource.com/c/v8/v8/+/1933054

[devsnek]

I also opened https://bugs.webkit.org/show_bug.cgi?id=204629

[allenwb]

3 is what the spec. has said going all the way back to ES3. This specified behavior was reviewed and confirmed during ES5 development Even though there there was considerable variation of the actual placement of properties among implementations at that time (ie, 2008) only one change was made to the specification. The initial value of _NativeError_.prototype.message was respecified to be the empty string. In ES3 it had been specified as "implementation defined".

However, it appears that the ES5 change did miss something. In ES3 the first paragraph in the "_NativeError_ Objct Structure" clause ended with:

and in the implementation-defined __message__ property of the prototype object.

The "implementation-defined" adjective should have been removed when the ES5 change was made. It wasn't and that incorrect text remains in the working draft. It should be removed.

[ljharb]

To summarize my interpretation of the state of this issue:

• editorial: the phrase "implementation-defined" should be removed from https://tc39.es/ecma262/#sec-nativeerror-object-structure, a PR is welcome (@bathos?)
• existential: should the spec find some way of ensuring that implementation extensions do not shadow inherited properties on a builtin with an own property that the spec does not define?

Thoughts?

[rkirsling]

As of the latest V8 and WebKit revisions (_Chrome and Safari releases notwithstanding_) the chart should now be 3s everywhere.

[devsnek]

^ chakra still has this bug, but its not in any browser

[ljharb]

Has an issue been filed on ChakraCore?