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/CANh-dXmSBUvWgaL8efCVGrSNHRhUSnQWVLZw%2BQmv1FjgfxE2uA%40mail.gmail.com.
