While I share Alex's general concern (see https://github.com/w3ctag/design-principles/issues/426#issuecomment-3824607888), I tend to agree that the I2S is not the right place for this debate.
Seeing no open issues for the API on the spec / PR, and reading TAG's guidance that adding APIs on the global is at least sometimes reasonable, I don't personally think API owners are in a position to block on this. LGTM4 once the PR lands. On Fri, Jan 30, 2026, 4:05 a.m. Dominic Farolino <[email protected]> wrote: > 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/CAFUtAY8QngZEp-Rp3KnVeE%2Bb2YcTL_sNVZ8DLJQ9fggjp7eVPw%40mail.gmail.com.
