Call stacks in crash reports from unresponsive web pages

[issackjohn]

こんにちは TAG-さん!

I'm requesting a TAG review of Call stacks in crash reports from unresponsive web pages.

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.

• Explainer¹ (minimally containing user needs and example code): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
• Specification URL: https://wicg.github.io/crash-reporting/
• Tests: N/A
• User research: N/A
• Security and Privacy self-review²: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/security-privacy.md
• GitHub repo: https://github.com/WICG/crash-reporting
• Primary contacts (and their relationship to the specification):
  • [name] ([github username]), [organization/s] (repeat as necessary, we recommend including group chairs and editors in this list)
  • Ian Clelland (@clelland), Google, Author
  • Issack John (@issackjohn) Microsoft
  • Seth Brenith (@sethbrenith) Microsoft
• Organization(s)/project(s) driving the specification: WICG/crash-reporting
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification
• Key pieces of multi-implementer support:
  • Chromium comments: https://issues.chromium.org/issues/40268201
  • Mozilla comments: Call stacks in crash reports from unresponsive web pages mozilla/standards-positions#1057
  • WebKit comments: Call stacks in crash reports from unresponsive web pages WebKit/standards-positions#380
  • etc...
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Chrome Status: https://chromestatus.com/feature/4731248572628992

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines:
• The group where the work on this specification is currently being done: WICG Crash Reporting
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C Web Performance WG
• Major unresolved issues with or opposition to this specification: N/A
• This work is being funded by:

You should also know that...

---

[jyasskin]

This looks like a worthwhile piece of information to show to developers. We agree with the privacy worries that these uploads might expose what extensions a user is running. We suspect this privacy risk is avoidable in two ways: First, you could automatically omit stacks if any extensions have injected content scripts. Second, you could prompt the user about whether they want to send the report, with a user-comprehensible explanation of what sensitive information's likely to be sent: for example the list of extensions that injected script.

Please continue discussing this in the WebPerf working group and the PING.