ReportingAPI: List of reports - draft

[hamishwillee]

This is in progress work to provide a list of all reports and how they are accessed for reporting API.
Fixes #43688

This will have the parent grouping. Still working on the pages that it needs before this can go in though. This is all being tested still.

• Document-Policy violations https://wicg.github.io/document-policy/#configure-reporting and https://chromestatus.com/feature/5756689661820928 and Please add Document Policy to MDN mdn#394 and https://github.com/WICG/document-policy/blob/main/document-policy-explainer.md
• Permission policy violations
  • ReportingAPI: PermissionPolicyViolationReport #43783
  • Add ReportingObserver report type permissions-policy-violation browser-compat-data#29500
• Network errors - to be done - see https://w3c.github.io/network-error-logging/#concept-network-error-reports https://w3c.github.io/network-error-logging/#nel-response-header Network Error Logging
• Crash reports
  • Technical review: Document crash reporting api #43791
  • Chrome 145 Crashing reporting, crash report type browser-compat-data#29475
• coop to be done - (spec)
• csp-next - https://wicg.github.io/csp-next/scripting-policy.html - appears dormant and not implementd

[github-actions]

[markdownlint] _{reported by reviewdog 🐶}
error MD001/heading-increment Heading levels should only increment by one level at a time [Expected: h4; Actual: h5]

[github-actions]

Preview URLs (1 page)

• /en-US/docs/Web/API/Reporting_API

Flaws (6)

Found an unexpected or unresolvable flaw? Please report it here.

URL: /en-US/docs/Web/API/Reporting_API
Title: Reporting API
Flaw count: 6

• macros:
  • Macro domxref produces link /en-US/docs/Web/API/COOPViolationReport which doesn't resolve
  • Macro domxref produces link /en-US/docs/Web/API/CrashReport which doesn't resolve
  • Macro domxref produces link /en-US/docs/Web/API/DocumentPolicyViolationReport which doesn't resolve
  • Macro httpheader produces link /en-US/docs/Web/HTTP/Reference/Headers/Document-Policy which doesn't resolve
  • Macro domxref produces link /en-US/docs/Web/API/NetworkErrorReport which doesn't resolve
  • and 1 more flaws omitted

[chrisdavidmills]

@hamishwillee, as an FYI, I'm working on the Crash Reporting API docs right now.

One thing I am confused about with the docs for the reporting APIs — the dictionary pages are titled xReport, for example, DeprecationReport, but the corresponding API entries in the specs are called xReportBody, for example, DeprecationReportBody. I'm assuming that this is because the ReportingObserver returns report objects that the body objects are contained within, but I really don't get where or how this is specified.

Crash reports are not observed by reporting observers; they are just sent to the server endpoints directly when a crash occurs. This being the case, should I still call the corresponding dictionary page CrashReport rather than CrashReportBody? This stuff is confusing as hell.

I'll get on with it anyway, and produce a draft to look at.

[hamishwillee]

Crash reports are not observed by reporting observers; they are just sent to the server endpoints directly when a crash occurs. This being the case, should I still call the corresponding dictionary page CrashReport rather than CrashReportBody? This stuff is confusing as hell.

@chrisdavidmills This has a long and still messy history. The original Reporting API defined Report and ReportBody interfaces, and implementations were supposed to derive from ReportBody. The spec changed a ciouple of years ago to make Report and ReportBody into dictonaries, and updated some of the derived report bodies to match. This is still all a mess where some have been migrated, some have not, and some don't derive from anything at all and therefore have no spec name. Following the suggestion of BCD we agreed to assume that we should document as though everything had migrated.

So the short version is, we document reports as dictionaries. Following MDN practise we don't document intermediate dictionaries, we just document the top level dictionary. Hence the pattern you see were we document the whole derived report and assume nothing is derived. Make sense?

[hamishwillee]

Crash reports are not observed by reporting observers; they are just sent to the server endpoints directly when a crash occurs. This being the case, should I still call the corresponding dictionary page CrashReport rather than CrashReportBody? This stuff is confusing as hell.

Yes. You have done it as I would. The point of THIS PR is to list all the reports you might get, and also to track the missing ones.