Call stacks in crash reports from unresponsive web pages

[issackjohn]

WebKittens

No response

Title of the spec

Call stacks in crash reports from unresponsive web pages

URL to the spec

https://wicg.github.io/crash-reporting

URL to the spec's repository

https://github.com/WICG/crash-reporting

Issue Tracker URL

https://issues.chromium.org/issues/40268201

Explainer URL

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md

TAG Design Review URL

w3ctag/design-reviews#981

Mozilla standards-positions issue URL

mozilla/standards-positions#1057

WebKit Bugzilla URL

No response

Radar URL

No response

Description

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.

What happens instead? The page reports that it was terminated due to being unresponsive, but the developer of the page has no further information about how to fix the problem.

[annevk]

There's an indication that this might impact the end user and therefore end user consent is important. However, the opt-in provided by the feature does not guarantee there is end user consent. It just gives web developer consent. What gives?

(Also, I don't think WebKit has taken a position on Crash Reporting in general, that probably warrants its own issue on which this would be blocked.)