annevk
commented
3 months ago 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.)
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
https://github.com/w3ctag/design-reviews/issues/981
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/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.