Contact emails
d...@chromium.org,
james...@google.com
Explainer
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
Specification
https://github.com/WICG/crash-reporting/pull/37
Summary
A new key-value API, tentatively `window.crashReport`, backed by a per-Document map holding data that gets appended to crash reports.
See
https://github.com/WICG/crash-reporting/issues/15 for initial discussion. The data placed in this API's backing map gets sent in the `CrashReportBody` [1] if any renderer process crashes are incurred by the site. This lets developers debug what specific state in their application might be causing a given crash.
[1]:
https://wicg.github.io/crash-reporting/#crashreportbody
Blink component
Blink>ReportingObserver
Web Feature ID
kDRAFT_CrashReportStorageAPIInitialize
Motivation
The Crash Reporting API (
https://wicg.github.io/crash-reporting/) allows developers to know when their site is crashing in the wild, and get some very rudimentary information associated with each crash. But developers don't have enough to go off to debug the crash further.
The feature
https://chromestatus.com/feature/4731248572628992 allows developers to get a JavaScript stack trace, but only for unresponsive crashes. Outside of this narrow case, developers have a hard time tying their specific logic or features to a real-world crash.
The `window.crashReport` API exposes a light-weight key-value store that developers can use to store breadcrumbs of their app state, which get appended to crash reports that get sent to their developer-specified endpoints. This significantly helps developers pinpoint the cause of a crash they're seeing in the wild, and radically speed up their debugging cycle.
Initial public proposal
https://github.com/WICG/crash-reporting/issues/15
TAG review
No information provided
TAG review status
Issues addressed
Origin Trial Name
CrashReportingStorageAPI
Chromium Trial Name
CrashReportingStorageAPI
Origin Trial documentation link
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md
WebFeature UseCounter name
WebDXFeature::kCrashReportStorageAPIInitialize
Risks
Debuggability
This feature could benefit by DevTools integration, to help developers more ergonomically interact with data in the crash report storage. We're considering this integration as a follow-up to support our partners, in the first half of 2026.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
No
This feature is not fully testable with Web Platform Tests, because WPT infrastructure does not provide the ability to crash specific renderer processes. This limitation has not prevented the Crash Report Infrastructure from shipping in general, nor has it prevented additions like
https://chromestatus.com/feature/4731248572628992.
This API will be tested with as many web platform tests as possible to assert the shape and semantics of the JS-exposed web API.
Flag name on about://flags
CrashReportingStorageAPI
Finch feature name
CrashReportingStorageAPI
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/400432195
Availability expectation
My expectation is that the feature is available only in Chromium browsers for at least 12 months, with a possible (seems likely) implementation in Firefox to follow.
Adoption expectation
We expect the feature to be used by a very small number of large partners with uniquely complicated, memory-intensive web applications, and comprehensive client and server-side debugging infrastructure. These partners will be using the API well within 12 months of launch in Chrome.
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium
open source repository and its open-source dependencies to
function?
No
Estimated milestones
| Shipping on desktop | 145 |
| Origin trial desktop first | 140 |
| Origin trial desktop last | 142 |
| Origin trial extension 1 end milestone | 145 |
| Shipping on Android | 145 |
| Origin trial Android first | 140 |
| Origin trial Android last | 142 |
| Shipping on WebView | 145 |
| Origin trial WebView first | 140 |
| Origin trial WebView last | 142 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
We're considering ergonomic additions to the API in the near future, such as:
- The ability to retrieve keys placed in the crash storage
- The ability to reset the storage entirely (freeing it), and re-request a different amount later
The API has been designed in a way that does not preclude any of these additions.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6228675846209536?gate=5081221847318528
Links to previous Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/687500b2.170a0220.1c6204.01c6.GAE%40google.comIntent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/688a7245.2b0a0220.35091d.043b.GAE%40google.comIntent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e67fd8.050a0220.3258b8.09b7.GAE%40google.com