Thanks for taking this on!!
Is this WPT-testable?
// DocumentPolicyViolation is now dictionary-based
I wonder if it makes sense to create a dictionary-based LocationReportBody. WDYT?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[CallWith=ScriptState] readonly attribute any body;
Can't this return a `ReportBodyDict` instead of `any`?
[Exposed=(Window, Worker)] interface ReportBody {
Let's not reformat any of this if we're not materially changing it.
DOMString? sourceFile;
Hmm, how does this match the spec PR? The spec PR shows that `ReportBody` is a completely empty dictionary. Surely not every single "derived" instance of `ReportBodyDict` should get these members.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
implementation to align with W3C Reporting API specification changes.
Please link to https://github.com/w3c/reporting/pull/284/files from here if possible.
[CallWith=ScriptState] readonly attribute any body;
Also, this is definitely a breaking change, right? That is, the `body` returned from this getter will no longer have a `toJSON()` method of its own, which seems like it could cause compatibility issues for sites currently relying on it.
@Yoav: do you know what the story is here? I'm a little surprised the spec PR landed so smoothly with this breaking web-observable change, unless I'm misunderstanding how this is wired up.
Either way, this does seem web-observable for any callers of the "new" `Report` constructor that pass in a dictionary instead of a `ReportBody` interface object. And there is at least one new user of that constructor introduced in this CL (in `third_party/blink/renderer/core/frame/local_dom_window.cc`), so we should flag guard this. Author: could you add a new runtime enabled feature for this, so that we can flag-guard all of the web-observable changes?