I filed a question on the specification repository which I'd like to see discussed before we ship this: https://github.com/WICG/crash-reporting/issues/26
On Wed, May 14, 2025 at 6:21 AM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails d...@chromium.org > > Explainer https://github.com/WICG/crash-reporting/issues/20 > https://github.com/WICG/crash-reporting/issues/14 > https://github.com/WICG/crash-reporting/pull/23 > > Specification https://github.com/WICG/crash-reporting/pull/23 > > Design docs > https://github.com/WICG/crash-reporting/pull/23 > > Summary > > This feature adds `is_top_level` and `visibility_state` string fields to > the crash reporting API body that gets sent to the default reporting > endpoint for crash reports. See > https://wicg.github.io/crash-reporting/#crash-report. For `is_top_level`: > see https://github.com/WICG/crash-reporting/issues/20 & > https://github.com/WICG/crash-reporting/pull/23. The string value "true" > or "false" is included depending on whether the Document sending the crash > report belongs to a top-level traversable navigables. For > `visibility_state`: see > https://github.com/WICG/crash-reporting/issues/14#issuecomment-2452393164. > > > Blink component Blink > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> > > TAG review This seems like a very trivial addition to an existing API > that does not justify a full TAG specification review. > > TAG review status Not applicable > > Risks > > > Interoperability and Compatibility > > There are no discernible compatibility risks. Interop-wise, we've received > good remarks (but not yet formal support) from Mozilla about this change > during a Web Perf WG meeting; we have not yet heard from Safari. I believe > the interop risks for this proposal are very minimal. > > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/1225) I marked this > as positive because the entire crash reporting API was marked as supportive > by Mozilla in https://github.com/mozilla/standards-positions/issues/288, > and Martin pointed to that when I filed a more specific one for these two > small additions. > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/456#issuecomment-2859201260) > > > *Web developers*: Positive Internal partners are very happy to receive > this kind of new information in the crash report JSON body. > > *Other signals*: > > Security > > This proposal is sending information with a crash report, that developers > already have access to, and could be sending to their own servers manually > to keep track of application responsiveness or to estimate a crash. With > this, we believe there are no security concerns with including this > information in crash report bodies. > > > 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? > > None > > > Debuggability > > None > > > 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 > > There are no web platform tests for this tiny addition to the crash > reporting API, because the crash reporting API itself cannot be tested this > way at the moment. WPTs do not support crashing the renderer process for a > contrived set of reasons (OOM, unresponsiveness, etc). Note that this has > been documented in all of the other parts of this API that have shipped. > See https://groups.google.com/a/chromium.org/g/blink-dev/c/tgRcEnqIb1A, > for example. > > > Flag name on about://flags None > > Finch feature name CrashReportingAPIMoreContextData > > Rollout plan Will ship enabled for all users > > Requires code in //chrome? False > > Estimated milestones > Shipping on desktop 138 > Shipping on Android 138 > Shipping on WebView 138 > > 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). > None > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5182880216776704?gate=5113784913625088 > > 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 blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6823b7ea.050a0220.624fd.0209.GAE%40google.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6823b7ea.050a0220.624fd.0209.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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-_A7rT%3Dc9V2UX1SuYgqsfDm5omjYU3WW%3D8udqhftua3A%40mail.gmail.com.
