v137 · miscellaneous

Call stacks in crash reports from unresponsive web pages

This feature captures the JS call stack when a web page becomes unresponsive due to JavaScript code running an infinite loop or other very long computation. This helps developers to identify the cause of the unresponsiveness and fix it more easily. The JS call stack is included in the crash reporting API when the reason is unresponsive.

concepts

  1. Crash Stack

    Crash reports for unresponsive web pages now include JS call stacks. Critical signal for diagnosing main-thread freezes in production.

  2. Endpoint Inbox

    Server-side Reporting-Endpoints config + a ReportingObserver in-page mirror, side-by-side with the synthesised crash payload that would land at your endpoint.

  3. Report Viewer

    Paste a real Reporting API crash payload (or use the included samples) and the viewer renders the frames, highlights the top frame, and shows the cluster key an aggregator would group on.

  4. Stack Source Mapper

    Paste the Error.prototype.stack-style string from an unresponsive crash report, apply a source-map lookup, and see the original source location an endpoint would group on. Presets include minified stacks, missing mappings, and malformed copied logs.

why it shipped

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.

references