Intent to Experiment: Crash Reporting key-value API

[Chromestatus]

Contact emails

d...@chromium.org

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

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1271)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/528)

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:

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?

None

Goals for experimentation

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

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

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/400432195

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6228675846209536?gate=5172180396277760

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

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

On Thursday, July 31, 2025 at 4:28:22 AM UTC+9 Chromestatus wrote:

Contact emails d...@chromium.org

Explainer https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md

Specification https://github.com/WICG/crash-reporting/pull/37

I've noted a few issues, which do not block origin trial but might be worth addressing beforehand since they change the observable impact of the API:

• https://github.com/WICG/crash-reporting/issues/38
• https://github.com/WICG/crash-reporting/issues/39
• https://github.com/WICG/crash-reporting/pull/37/files#r2244219210

 

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

TAG review None

TAG review status Pending

It's probably a good idea to file for one at this stage? (But not necessarily required.)

 

Risks

Interoperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1271)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/528)

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:

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?

None

Goals for experimentation

Can you paste this in? The generated email is buggy per https://github.com/GoogleChrome/chromium-dashboard/issues/4155 . 

 

Ongoing technical constraints

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No

Why not?

 

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

Requires code in //chrome? False

Tracking bug https://issues.chromium.org/issues/400432195

Estimated milestones

No milestones specified

Can you add estimated milestones?

[Dominic Farolino]

I've noted a few issues, which do not block origin trial but might be worth addressing beforehand since they change the observable impact of the API:

Thanks! Everything has now either been commented on, or is on its way to being addressed. I hope to get any API changes in before the M140 branch, but if I miss it we will either communicate the upcoming API changes to partners, or merge backwards. The number of partners directly interested in this right now is limited, so it should be easy to communicate the exact timeline of any minor API changes to them without causing much disruption.

It's probably a good idea to file for one at this stage? (But not necessarily required.)

Yep, this was on my TODO list but didn't quite make the cut. I just did it: https://github.com/w3ctag/design-reviews/issues/1129.

 Can you paste this in? The generated email is buggy per https://github.com/GoogleChrome/chromium-dashboard/issues/4155 . 

Oh, interesting. Our goal is to work with our internal partner to test out whether this API is enough to help them track down and avoid a few high-profile crashes in their product. If allowing them to supply arbitrary application state allows them to meaningfully reduce their renderer process crash rate in a way that they couldn't do before, we will consider any small remaining API changes, and look to ship the feature to the web!

Can you add estimated milestones?

Sorry, I'm not sure why this didn't get populated. An M140 origin trial is our goal. 

[Chris Harrelson]

LGTM to experiment.

(I see you also said on the chromestatus entry that it's supported on all platforms - great!)

--
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-uykCRyF8URgG%2B37dcy3KPxp98M3-R%3DLk4y_EoT1UX3KUrBQ%40mail.gmail.com.