Revise descriptions for ReportingObserver() report types by chrisdavidmills · Pull Request #29475 · mdn/browser-compat-data

chrisdavidmills · 2026-04-14T08:26:48Z

Summary

Chrome 145 adds support for the Crash Reporting API; see https://chromestatus.com/feature/6228675846209536.

Most of the BCD for this API has already been added; however, I wanted to add a data point for the crash report type. The data for the different report types is contained under api.ReportingObserver.ReportingObserver.options_parameter.types_property, so I added it under there. This data is also used as the BCD for each report type dictionary; I'll need it when documenting CrashReportBody.

This is a bit weird, as crash reports aren't observed by reporting observers, but I think you can still specify them as a valid report type in the constructor types list.

Test results and supporting details

Related issues

github-actions · 2026-04-14T08:27:32Z

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

caugner · 2026-04-17T21:04:38Z

+                ],
+                "support": {
+                  "chrome": {
+                    "version_added": "145"


This is a bit weird, as crash reports aren't observed by reporting observers, but I think you can still specify them as a valid report type in the constructor types list.

If this report is never observed in the only implementing browser, then we should probably mention this in the notes? However, it is also not really clear what support means then if there is no effect?

I've tried adding a note to explain this. Let me know what you think. This is a weird situation, but it is still useful to know that the report type is not observed.

caugner · 2026-04-22T07:16:04Z

+                "support": {
+                  "chrome": {
+                    "version_added": "145",
+                    "notes": "The `crash` report type can be specified in the `types` array, but crash reports are not observed by reporting observers. They can be sent to reporting endpoints."
+                  },


I think this note can be helpful, but I'm still wondering what "supported" means here versus not supported. Does setting the type to crash in an earlier version have a different behavior, for example throwing an error?

/cc @ddbeck for a 2nd opinion

It basically just means that crash is a recognised type. I've tested it, and unfortunately, it doesn't throw if an unrecognized type is included in the options object.

The main reaosn I'm adding this here is because of this note in the description:

This data is also used as the BCD for each report type dictionary; I'll need it when documenting CrashReportBody.

Because we don't record BCD separately for dictionaries, I need this data point to show BCD in the new dictionary page I'm documenting. This is how it was decided for the reporting dictionaries.

Why will you need it when documenting crash report bodies—can you say more about this? If you need a way to show support for receiving crash report bodies, would http.headers.Reporting-Endpoints.crash-reporting suffice (see #29399)?

I guess it is for consistency more than anything. This is what we've used to represent the BCD for all the other reporting dictionaries.

Also, there is a bit of a version mismatch. The data you've added says Chrome 139, but the bits I've just bene documenting say Chrome 145. https://developer.mozilla.org/en-US/docs/Web/API/CrashReportContext#browser_compatibility, for example.

I'd say it's inconsistent to say that ReportingObserver() has anything to do with crash reporting. 🤷

As for the header data, there's no inconsistency but there is a part missing:

CrashReportContext is part of the crash report context key-value API. It's new in Chrome 145.

http.headers.Reporting-Endpoints.crash-reporting is the named endpoint for crash reports. It's new in Chrome 139.

Here's the missing part: Since Chrome 73, crash reports go to the default crash reporting endpoint (citation). We could have some keys like http.headers.Reporting-Endpoints.default, http.headers.Reporting-Endpoints.default.receives_crash_type, and http.headers.Reporting-Endpoints.default.receives_deprecation_type to track this.

On the last point, would that solve the problem for crash report bodies?

See also mdn/content#43688 and cc: @hamishwillee.

I'd say it's inconsistent to say that ReportingObserver() has anything to do with crash reporting. 🤷

Yeah, I guess it is. I was just trying to follow the pattern laid out for the other reporting body dictionaries, but I see your point.

As for the header data, there's no inconsistency but there is a part missing:

* `CrashReportContext` is part of the crash report context key-value API. It's new in Chrome 145. * `http.headers.Reporting-Endpoints.crash-reporting` is the named endpoint for crash reports. It's new in Chrome 139.

Hrm, neither of those sounds like the data that should be used to represent CrashReportBody.

* Here's the missing part: Since Chrome 73, crash reports go to the `default` crash reporting endpoint ([citation](https://chromestatus.com/feature/6683949661159424)). We could have some keys like `http.headers.Reporting-Endpoints.default`, `http.headers.Reporting-Endpoints.default.receives_crash_type`, and `http.headers.Reporting-Endpoints.default.receives_deprecation_type` to track this.

On the last point, would that solve the problem for crash report bodies?

This sounds more like the data we want to use for CrashReportBody. Shall I remove the crash data point from this PR (I think the type fix on line 107 could still do with fixing), and open a new PR to add the data you're proposing here?

See also mdn/content#43688 and cc: @hamishwillee.

Shall I remove the crash data point from this PR (I think the type fix on line 107 could still do with fixing), and open a new PR to add the data you're proposing here?

That sounds good to me. Feel free to tag me for review on it when it opens.

That sounds good to me. Feel free to tag me for review on it when it opens.

OK, I'll get on it. Thanks for the help in resolving this, @ddbeck.

…stent

ddbeck · 2026-04-24T16:40:30Z

Approved, but before merging I'd recommend renaming this PR to something like "Revise descriptions for ReportingObserver() report types"

chrisdavidmills · 2026-04-27T09:04:02Z

Approved, but before merging I'd recommend renaming this PR to something like "Revise descriptions for ReportingObserver() report types"

Done. Thanks, @ddbeck!

Chrome 145 Crashing reporting, crash report type

3632157

github-actions Bot added data:api Compat data for Web APIs. https://developer.mozilla.org/docs/Web/API size:m [PR only] 25-100 LoC changed labels Apr 14, 2026

chrisdavidmills requested a review from caugner April 14, 2026 08:27

hamishwillee mentioned this pull request Apr 17, 2026

ReportingAPI: List of reports - draft mdn/content#43782

Draft

10 tasks

caugner reviewed Apr 17, 2026

View reviewed changes

chrisdavidmills added 2 commits April 20, 2026 12:15

Add explanatory note

1d7b031

fix typo

7de6deb

chrisdavidmills requested a review from caugner April 20, 2026 11:18

caugner reviewed Apr 22, 2026

View reviewed changes

chrisdavidmills added 3 commits April 24, 2026 11:35

Merge branch 'main' into crash-reporting-api

1203bf2

Remove crash type value data, as discussed

859d6ea

restore report type that got removed somehow, make descriptions consi…

7e0b7df

…stent

github-actions Bot added size:s [PR only] 7-24 LoC changed and removed size:m [PR only] 25-100 LoC changed labels Apr 24, 2026

chrisdavidmills requested a review from ddbeck April 24, 2026 10:49

chrisdavidmills mentioned this pull request Apr 24, 2026

Add Reporting-Endpoints header data on default endpoints usage #29539

Merged

ddbeck approved these changes Apr 24, 2026

View reviewed changes

chrisdavidmills changed the title ~~Chrome 145 Crashing reporting, crash report type~~ Revise descriptions for ReportingObserver() report types Apr 27, 2026

chrisdavidmills merged commit 7d2347f into mdn:main Apr 27, 2026
9 checks passed

chrisdavidmills deleted the crash-reporting-api branch April 27, 2026 09:04

Conversation

chrisdavidmills commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test results and supporting details

Related issues

Uh oh!

github-actions Bot commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddbeck commented Apr 24, 2026

Uh oh!

chrisdavidmills commented Apr 27, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

chrisdavidmills commented Apr 14, 2026 •

edited

Loading

github-actions Bot commented Apr 14, 2026 •

edited

Loading