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.
