Hmm, I'm a bit surprised to have this discussion here on the I2S rather than on the design-principles thread, trying to drive consensus there. I honestly think for this API it's best to proceed with the LGTMs and current feedback we've got from existing editors, TAG, and (informally) other browsers, and re-litigate the `window` vs `navigator` discussion with the TAG to the point of consensus, so we can avoid further instances of confusion.
On Wed, Jan 28, 2026 at 11:08 AM Alex Russell <[email protected]> wrote: > 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/CAP-uykAREBG%2Bq5GhMFv_LPid3ekog-sn0XdCHLS_gFcnkJKHBw%40mail.gmail.com.
