Intent to Ship: Crash Reporting key-value API

[Chromestatus]

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

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?

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.

[Mike Taylor]

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.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.com.

[Rick Byers]

This looks great, I'm excited to see this ship! Just a couple questions:

Is there anything blocking getting the spec PR landed?

I think it's probably fine not to block on WPT tests for landing this, but if Mozilla is (as you say) likely to start working on an implementation over the next year then I'm guessing that they'd prefer we explore the feasibility of adding WPT infrastructure. @Philip Jägenstedt likely has thoughts on this. 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.

[Dominic Farolino]

Is there anything blocking getting the spec PR landed?

Actually, no. Possibly minor editorial things I need to wade through, but otherwise no. I'll get on landing it.

I think it's probably fine not to block on WPT tests for landing this, but if Mozilla is (as you say) likely to start working on an implementation over the next year then I'm guessing that they'd prefer we explore the feasibility of adding WPT infrastructure.

Right, this API is still a priority and staffed, so if such a signal comes in, getting all the WPT infrastructure worked out will become a priority and something we will lead, since the utility will be clear.

[Alex Russell]

It seems strange for us to be expanding the set of things that live on `window`; was the TAG consulted?

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+unsubscribe@chromium.org.

[Dominic Farolino]

Yes, I filed a TAG review in https://github.com/w3ctag/design-reviews/issues/1129 (sorry it didn't show up in the original email, hmm...). This specific point was not raised by them, however I did address the renames they proposed. I understand there has been some discussion on `window` and namespacing in https://github.com/w3ctag/design-principles/issues/426, however the TAG has not reached consensus. On that issue in particular, I tend to agree with Anne and Domenic's view though (against namespacing).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+...@chromium.org.

[Jeffrey Yasskin]

The TAG has an open design-principles issue at https://github.com/w3ctag/design-principles/issues/448, which asks the question of 'window' vs 'document'. We haven't pushed this to consensus, but Domenic's position will be influential, and my read of it argues to put this on Window or WindowOrWorkerGlobalScope. The TAG did miss the question of whether this would be useful to workers.

Jeffrey

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.com.

[Dominic Farolino]

Window or WindowOrWorkerGlobalScope is right for this, IMO. I think WindowOrWorkerGlobalScope would be better, but right now the Crash Reporting infrastructure (beyond this API) only considers documents / RenderFrameHosts, and does not apply to Workers. I think this is a legacy artifact of how Crash Reporting was implemented a while back (it seems old; I've only recently added to it). I can envision implementation and spec changes in the future to cover Workers, in which case we could move the API to WindowOrWorkerGlobalScope with little pain, but since the overall infra is not implemented for workers, putting the crashReport API there doesn't quite work at the moment.

[Yoav Weiss (@Shopify)]

LGTM2 conditional on landing the PR

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.

--
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 blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.

--
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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9740935d-9a56-4705-b497-7672a7b14db3n%40chromium.org.

[Alex Russell]

Let me be a bit more direct: it's a bad smell for us to be putting things on Window if we can avoid it. Are you willing to move this to `navigator`?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.

--
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 blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.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 blink-dev+unsubscribe@chromium.org.

[Dominic Farolino]

Hmm, I'm a bit surprised to have this discussion here on the I2S rather than on the design-principles thread, trying to drive consensus there. I honestly think for this API it's best to proceed with the LGTMs and current feedback we've got from existing editors, TAG, and (informally) other browsers, and re-litigate the `window` vs `navigator` discussion with the TAG to the point of consensus, so we can avoid further instances of confusion.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69723029.710a0220.3080c5.03ca.GAE%40google.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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org.

--
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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.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 blink-dev+...@chromium.org.

[Rick Byers]

While I share Alex's general concern (see https://github.com/w3ctag/design-principles/issues/426#issuecomment-3824607888), I tend to agree that the I2S is not the right place for this debate.

Seeing no open issues for the API on the spec / PR, and reading TAG's guidance that adding APIs on the global is at least sometimes reasonable, I don't personally think API owners are in a position to block on this.

LGTM4 once the PR lands.