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/CAP-uykDsd_yr8vVcX2%3DRfGPv%2BJtVTZCPGdn-OnLsrbSCFK9%2BqA%40mail.gmail.com.
