LGTM2 conditional on landing the PR On Tuesday, January 27, 2026 at 9:39:50 PM UTC+1 Dominic Farolino wrote:
> 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 Window*OrWorkerGlobalScope* 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. > > On Mon, Jan 26, 2026 at 6:52 PM Jeffrey Yasskin <[email protected]> > wrote: > >> 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 >> >> On Mon, Jan 26, 2026 at 11:48 AM Dominic Farolino <[email protected]> >> wrote: >> >>> 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). >>> >>> On Mon, Jan 26, 2026 at 2:37 PM Alex Russell <[email protected]> >>> wrote: >>> >>>> It seems strange for us to be expanding the set of things that live on >>>> `window`; was the TAG consulted? >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Monday, January 26, 2026 at 4:48:24 AM UTC-8 Dominic Farolino wrote: >>>> >>>>> 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-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykB0%2BRBpXnB9WP9L8V99c6aqM5FMGE9XuL%2Bo5DnnGg0FUA%40mail.gmail.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/9740935d-9a56-4705-b497-7672a7b14db3n%40chromium.org.
