> > 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. On Mon, Jan 26, 2026 at 6:03 AM Rick Byers <[email protected]> wrote: > 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 > <[email protected]> likely has thoughts on this. > > On Fri, Jan 23, 2026 at 2:53 AM Mike Taylor <[email protected]> > wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2996239-e188-4964-acca-c930020a1dbc%40chromium.org?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/CAP-uykDth6xeY1GFYShYGzut0E7sgXgBF2JUvJMy0PGGFPCv1Q%40mail.gmail.com.
