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

@caugner Thanks for your attention and taking this up in the BCD meeting.

The spec is now updated in w3c/reporting#284 so Report and ReportBody are dictionaries. Of course they will be in the IDL for all the current bodies etc until code can be changed, and hence exposed on the global object.

But what this means is that this has become a "real" problem affecting all the current report types.
Adding this to Report as I have done may not be the right thing.

If BCD is going to avoid dictionaries then the only option I see here is to add the information somehow to ReportingObserver.

The actual place the objects appear is in a callback method that you pass to the ReportingObserver constructor. This really doesn't have something you can hook to, so maybe the right place would be as a set of subfeatures of ReportingObserver with keys like reports_coep, reports_csp-...

EDIT PS, I think this does mean we need to deprecate to_json in the ReportBody now. Going forward all of these will disappear if BCD is consistent in how it handles dictionaries. Don't know how you will handle the between times though.

@caugner And it just got even more messy in w3c/reporting#216 (comment) which seems to indicate that only report bodies which need to show up in ReportingObserver need a dictionary.

The implication, which I am checking, is that COOP and COEP report types only appear in reporting server endpoints - i.e. they are JSON objects posted to a server and not things you can get via ReportingObserver.

I have no idea what the "right thing" to do is now for COEP, COOP. Probably what we are proposing to do here, but you might argue that the information should go as a subfeature of the respective COOP / COEP headers - and I couldn't argue that.

But the discussion above is still value for the other reporting types.

I have no idea what the "right thing" to do is now for COEP, COOP.

It would be good to have another pair of eyes on this one, possibly @Elchi3 or @ddbeck.

@caugner I think the way this is now is the correct way to do this. Naming convention might not be right, but I think the approach is. Can you review?

The body type is changing so that instead of getting an interface it will get a dictionary (already in spec, but not changed for old cases in the implementations). My thinking therefore is that we need to be able to indicate what body types are supported inside the body feature like this:

- api
  - Report
    - type
	- body
	  - type_coep_dict
	  - type_csp-violation_CSPViolationReportBody
	  - type_intervention_InterventionReportBody
	  - etc....
	- url

So coep is defined as an unamed object (i.e. a dict with no name). So here we indicate that as something like type_coep_dict.

Right now a csp-violation Report.body is a CSPViolationReportBody, so we indicate that as type_csp-violation_CSPViolationReportBody. If it becomes a dictionary in an implementation we'd deprecate this feature, and mark the version removed. Then we'd add type_csp-violation_dict to indicate this is now a dict.

We don't record the subfeatures unless they change for the particular type.

The only other way to do this is perhaps to add subfeatures to indicate the existing report types are dictionaries, and the versions in which that happens - such as

- api.ReportBody
  - is_a_dictionary

- api.CSPViolationReportBody
  - is_a_dictionary

This is good for the docs, but I don't see that as workable for BCD because you still need to find some way to report the coep dict - which as a dict you won't able to add a record for. YOu'll also have all these derived dicts you'll need to remove at some point.

This came up on today's BCD call. I took a look at the spec and the discussion for it. I'm sorry that they've done this to you, Hamish.

If these really are dictionaries, then there's no real support story to talk about. The purist move would be to sidestep a lot of this:

• For api.Report and any other report dictionaries in api, set deprecated to true (taking the removal from the spec as a de facto deprecation). If a browser does not expose the interface, then set "version_added": false or "version_removed" accordingly.

• Show that developers can get reports of the various dictionary types via ReportingObserver. That is, make these features:

  api.ReportingObserver.ReportingObserver.options_parameter.types_property.csp-violation
  api.ReportingObserver.ReportingObserver.options_parameter.types_property.deprecation
  api.ReportingObserver.ReportingObserver.options_parameter.types_property.integrity-violation
  api.ReportingObserver.ReportingObserver.options_parameter.types_property.intervention
  

On MDN, I would suggest documenting the report body dictionaries as dictionaries (i.e., don't mention the interfaces). I would use the api.ReportingObserver.ReportingObserver.options_parameter.types_property.* keys for the compat tables on those pages, to show that those dictionaries exist.

@ddbeck Thank you so much - just the clear direction that I needed. This PR has been updated as you suggested in #27047 (comment)

Note, I did not mark the dictionaries as non-standard, though perhaps I should have.

@caugner Ready for re-review. Should be good.

For paper trail purposes: in chat, Hamish mentioned that DeprecationReportBody and InterventionReportBody are still interfaces in the specs (they inherit from the former ReportBody interface). I suggested that it's fine to treat these two interfaces deprecated by implication and to document them on MDN as if they were dictionaries. Right now, the spec'd interfaces say something impossible (inheritance from a non-existent interface), so we shouldn't take them literally.

@caugner Now that this satisfies @ddbeck can I get a re-review?

Note that I have just updated this for FF149 which releases support for the Reporting API, including CSP and Integrity-Policy. See https://bugzilla.mozilla.org/show_bug.cgi?id=2008916 and the changes made in #29135

• Some "interfaces" are not exposed to window context but they are supported in Firefox 149

If an interface is not exposed to window, does it "count" for support in BCD? If I can't do something like someObj instanceof DeprecationReportBody what does it mean for it to be supported? Is any anonymous object with a toJSON() method an implementation of the interface?

(I ask because I've had #19304 (comment) open in a tab for months and I'd like to figure out how to handle that.)

If an interface is not exposed to window, does it "count" for support in BCD?

Well these are "interfaces", so not really interfaces but rather dictionaries/objects and the implication is exactly that: not exposed to window contexts by design.

Since dictionaries are gone from BCD, we're in this situation rarely these days. But here we are again.

https://developer.mozilla.org/en-US/docs/Web/API/DeprecationReportBody#browser_compatibility is the compat table and I think code to test support that would "count" would be something like:

const options = {
  types: ["deprecation"],
  buffered: true,
};

const observer = new ReportingObserver((reports, observer) => {
  console.log(reports);
}, options);

observer.observe();
const records = observer.takeRecords();
console.log(records);
console.log(records[0].body instanceof DeprecationReportBody); // true
console.log(records[0].body.anticipatedRemoval)
// etc.

Thanks @Elchi3 - I've done a search on the enabled preference dom.reporting.enabled and fixed up all cases, so this should be good now. I'm not sure what we'll do in future when these really all turn into dictionaries. Sure we can record the report name in the type as done here, but I don't know what we'll do to tell users what has happened if browsers add remove properties at that point.