Let me be a bit more direct: it's a bad smell for us to be putting things on Window if we can avoid it. Are you willing to move this to `navigator`?
On Wednesday, January 28, 2026 at 6:49:16 AM UTC-8 Chris Harrelson wrote: > LGTM3 > > On Wed, Jan 28, 2026, 12:04 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9740935d-9a56-4705-b497-7672a7b14db3n%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/8dc49af9-9abb-4987-aab9-b4462533d69dn%40chromium.org.
