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/CAOMQ%2Bw_n0MSt0NHCsH%2BLh7cmKu3WLttRKQawpGW5yvVMgqs9Qg%40mail.gmail.com.
