LGTM1
DevTools integration seems like good follow up work - but given the
ephemeral (~session storage-like) nature of the storage, it seems easy
enough to clear state as-is.
On 1/22/26 9:11 a.m., Chromestatus wrote:
*Contact emails*
[email protected], [email protected]
*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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EReportingObserver%22>
*Web Feature ID*
kDRAFT_CrashReportStorageAPIInitialize
<https://webstatus.dev/features/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*
*Interoperability and Compatibility*
/No information provided/
/Gecko/: Under
consideration (https://github.com/mozilla/standards-positions/issues/1271)
https://github.com/mozilla/standards-positions/issues/1271 is under
consideration, but Mozilla is positive on the overall Crash Reporting
infrastructure
(https://github.com/mozilla/standards-positions/issues/288) and I've
received positive, informal feedback in Web Perf WG when presenting
this and asking Firefox engineers for feedback.
/WebKit/:
Negative (https://github.com/WebKit/standards-positions/issues/528) Their
concerns are not specific to this sub-API; they are concerned about
the overall crash reporting infrastructure.
/Web developers/: Positive First-party partners at Google are excited
to be able associate specific app state & data with web-exposed crash
reports.
/Other signals/:
*Security*
https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md#security-and-privacy-concerns
*WebView application risks*
Does this intent deprecate or change behavior of existing APIs, such
that it has potentially high risk for Android WebView-based applications?
/No information provided/
*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
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
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.com
Intent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/688a7245.2b0a0220.35091d.043b.GAE%40google.com
Intent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68e67fd8.050a0220.3258b8.09b7.GAE%40google.com
This intent message was generated by Chrome Platform Status
<https://chromestatus.com>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.
