Intent to prototype and ship: Error.stackTraceLimit

[Daniel Minor]

Summary:

Error.stackTraceLimit provides a flag that limits the depth of the JavaScript error stack, allowing developers to limit the depth of the collected stack as a performance optimization. The details are discussed on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stackTraceLimit.

This originated as a V8 only API, but JavaScriptCore has also shipped it, and we are seeing web compatibility problems due to not having an implementation.

Bug:
(to ship) https://bugzilla.mozilla.org/show_bug.cgi?id=2037856

(meta) https://bugzilla.mozilla.org/show_bug.cgi?id=2036771

Specification:
https://github.com/tc39/proposal-error-limit-option.

This proposal is currently at Stage 1, and does not specify the existing Error.stackTraceLimit behaviour. The proposal champion wants to remove Error.stackTraceLimit and replace it with an option to the Error object. While this is a better API, I am skeptical that this will be possible due to existing use on the web. Given that V8 and JavaScriptCore have already shipped this API, and we're seeing web compatibility problems due to not having it, I think the better approach is to specify both the legacy and new APIs to ensure interoperability.

Standards Body:

TC39

Platform Coverage:

All

Preference:
javascript.options.experimental.error_stack_trace_limit

DevTools Bug:

N/A

Extensions Bug:
N/A

Use Counter:
None

Standards-Positions Discussion:

N/A

Other Browsers:
    Blink/V8: Shipped
    WebKit/JSC: Shipped

web-platform-tests:

This feature would be covered by Test262, but no tests exist, due to the proposal being at Stage 1.

[Emilio Cobos Álvarez]

On 5/7/26 3:19 PM, 'Daniel Minor' via dev-pl...@mozilla.org wrote:
> This originated as a V8 only API, but JavaScriptCore has also shipped
> it, and we are seeing web compatibility problems due to not having an
> implementation.

Curious, could you elaborate? I could only find one bug [1], and I think
it's unlikely to be something widespread given the library involved and
the conditions that are required for it to break... Are there other
cases we know about?

That said, I guess it seems fine to do, specially given Safari shipped
it in a bug-for-bug compatible way to Chrome [2]...

I guess it'd be good to double-check if our implementation also has
those idiosyncrasies (if they're still there in other engines).

Thanks,
-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=2023811
[2]: https://bugs.webkit.org/show_bug.cgi?id=169904