Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions features/reporting-crashes-storage.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
name: Crash report storage
description: The `window.crashReport` object is a key-value store to record information about your application's state. If there's a crash, then the data in the key-value store is sent to your crash reporting endpoint, to help you pinpoint the cause of the crash.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this API builds on top of the Reporting API, which should likely be named here.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After re-reading a few resources, my understanding is now that:

  1. The Reporting API is the higher-level feature, which basically consists in defining a Reporting-Endpoints header to say where the browser should send (multiple types of) reports to.
    That's https://web-platform-dx.github.io/web-features-explorer/features/reporting/

  2. On top of this, the Crash Reporting API was defined. It's an extension of the Reporting API that's specifically made for reporting crashes, and which defines that reports contain data such as reason, stack, is_top_level, visibility_state, and crash_report_api.
    Spec: https://wicg.github.io/crash-reporting/
    We don't have a feature in the repo for this.

  3. The window.crashReport object, which seems to be and extension of the Crash Reporting API that lets developers also send their own custom data along with a crash report, but creating a map of key/value pairs
    Spec: https://wicg.github.io/crash-reporting/#crash-report-storage
    That's the new crash-report-storage feature you're proposing here.

I'm not 100% confident that 2 and 3 are separate things, but they do seem this way to me.

That said, I don't know if there are BCD keys for 2.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there are no practical benefits to creating a feature for 2 and 3, then we should at least revise the description to broaden the language so it encompasses the Crash Reporting API too.

spec: https://wicg.github.io/crash-reporting/#crash-report-storage
compat_features:
- api.CrashReportContext
- api.CrashReportContext.delete
- api.CrashReportContext.initialize
- api.CrashReportContext.set
- api.Window.crashReport
15 changes: 15 additions & 0 deletions features/reporting-crashes-storage.yml.dist
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Generated from: reporting-crashes-storage.yml
# Do not edit this file by hand. Edit the source file instead!

status:
baseline: false
support:
chrome: "145"
chrome_android: "145"
edge: "145"
compat_features:
- api.CrashReportContext
- api.CrashReportContext.delete
- api.CrashReportContext.initialize
- api.CrashReportContext.set
- api.Window.crashReport
25 changes: 25 additions & 0 deletions features/reporting-crashes.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
name: Crash reporting
description: Crash reporting sends a report to a URL nominated by the `Reporting-Endpoints` header when a user is unable to continue using the page because the browser or tab crashed.
spec: https://wicg.github.io/crash-reporting/
# This was first implemented in Chrome 72 via the now-deprecated `Report-To`
# header. Crash reporting thus predates `Reporting-Endpoints`. This somewhat
# strangely makes the `http.headers.Reporting-Endpoints` the de facto inception
# key for this feature. We can't (yet) overlap keys, so this status override is
# required for now. Further reading:
# - https://chromestatus.com/feature/6683949661159424
# - https://bugzilla.mozilla.org/show_bug.cgi?id=1860588
# - https://bugs.webkit.org/show_bug.cgi?id=269925
status:
baseline: false
support:
chrome: "96"
chrome_android: "96"
edge: "96"
firefox: "149"
firefox_android: "149"
compat_features:
# Include this key when https://github.com/web-platform-dx/web-features/issues/1173 is resolved:
# - http.headers.Reporting-Endpoints
# This key appeared later, allowing developers to opt-in to receiving _only_
# those reports, so it's excluded from the status calculation.
- http.headers.Reporting-Endpoints.crash-reporting
16 changes: 16 additions & 0 deletions features/reporting-crashes.yml.dist
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Generated from: reporting-crashes.yml
# Do not edit this file by hand. Edit the source file instead!

status:
baseline: low
baseline_low_date: 2026-03-24
support:
chrome: "96"
chrome_android: "96"
edge: "96"
firefox: "149"
firefox_android: "149"
safari: "16.4"
safari_ios: "16.4"
compat_features:
- http.headers.Reporting-Endpoints
2 changes: 1 addition & 1 deletion features/reporting.yml
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
name: Reporting API
description: The `Reporting-Endpoints` HTTP header and `ReportingObserver()` API send reports of Content Security Policy (CSP) violations, Permissions-Policy violations, deprecated feature usage, browser interventions, and crashes to a nominated URL or callback function.
description: The `Reporting-Endpoints` HTTP header and `ReportingObserver()` API send selected reports, such as Content Security Policy (CSP) violation reports or crash reports, to a nominated URL or callback function.
spec:
- https://w3c.github.io/reporting/
- https://wicg.github.io/intervention-reporting/
Expand Down
Loading