Summary

When a web page becomes unresponsive, it's often because of JavaScript code which is busy running an infinite loop or other very long computation. When a developer receives a report from the crash reporting API, and the reason is unresponsive, it would be very helpful to include the JS call stack from when the page was deemed unresponsive. This would let the website developer more easily find the find and fix the problem.

The following sections are my attempt to make this idea a bit more concrete, but I'd be fine with other options that satisfy the same overall goal.

A more detailed proposal

Crash reports uploaded by the Crash Reporting API may include the JavaScript call stack, in a new property on CrashReportBody:

readonly attribute DOMString? stack;

How is the stack represented?

Exactly the same format as Error.prototype.stack, including limiting the number of reported frames to the value specified in Error.stackTraceLimit. This format allows sites to reuse any logic they may have built for reading stacks uploaded by window.onerror handlers.

When should the stack be captured?

Any time after the browser has determined that the page or iframe is unresponsive. This leaves room for implementations to do whatever is most convenient, whether that be inspecting the stack of the process as it's terminated or interrupting the JS execution thread sometime earlier to collect the data.

What if a stack can't be captured?

That's fine. The browser should make a reasonable effort to collect call stack data, but such data is not guaranteed. For example, an implementation that relies on interrupting the JS thread may never have a chance to do so if that thread is waiting on a lock or executing a very long loop in browser-internal code.

What about workers?

An infinite loop in a worker doesn't cause the page or iframe to become unresponsive. This API reports only about script on the main thread.

Privacy

This is a new mechanism that could allow a website to collect data about its users. However, websites already have a great deal of power to collect data if they choose (including much more detailed data than is exposed by this proposal), and websites are responsible for respecting their users' privacy. As described in the Reporting API, browsers must provide an opt-out mechanism for reporting, which would block these reports entirely.

Security

Just like Error.prototype.stack, information must be omitted about any cross-domain scripts that were not loaded with CORS.

WICG / crash-reporting

Call stacks in crash reports from unresponsive web pages #12