1886820 - Consider adding support for Error.captureStackTrace

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Thomas Wisniewski [:twisniewski]]

WebKit quietly decided to implement this pretty recently [1], meaning Firefox is the only browser without support for this API.

We just saw our first webcompat issues [2] because of this.

[1] https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02
[2] https://github.com/webcompat/web-bugs/issues/134899

Comment 1

[Jan de Mooij [:jandem]]

Worth noting that the WebKit motivation was mostly performance:

We mostly want it because web tooling benchamrk uses it in the hot path of the chai-wtb test, where having native Error.captureStackTrace is a 5% progression over the polyfill.

According to that commit message, they diverge from V8 by making this a data property instead of an accessor. Bug 1740472 has some background on this. I wish they had followed V8 here instead of adding another potential web compat problem.

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to Jan de Mooij [:jandem] from comment #1)

Worth noting that the WebKit motivation was mostly performance:

We mostly want it because web tooling benchamrk uses it in the hot path of the chai-wtb test, where having native Error.captureStackTrace is a 5% progression over the polyfill.

According to that commit message, they diverge from V8 by making this a data property instead of an accessor. Bug 1740472 has some background on this. I wish they had followed V8 here instead of adding another potential web compat problem.

Also worth noting that there's no evidence this is a real-world performance improvement - the JetStream test in question is a test runner typically used in CI / server side environments so we should expect no performance improvement for real world users or content. It would have been much simpler to update the benchmark to drop the usage of the API, or the polyfill, than to ship an unspecified API to the web to improve the subtest score.