Contact [email protected]

Specificationhttps://w3c.github.io/reporting/#idl-index

Summary

Several interface objects used by the Reporting API were originally not
exposed as symbols on the JavaScript global object. This includes Report,
ReportBody, and the various specific report body types such as
CSPViolationReportBody and DeprecationReportBody. This change exposes those
objects on the window (or worker global), bringing the implementation in
line with the specification.


Blink componentBlink>ReportingObserver
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EReportingObserver>

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

The main risk here is that the newly-exposed symbols will collide with
symbols defined in existing scripts. Most of the names are quite specific,
but "Report" and "ReportBody" may have some existing use. However, this is
unlikely to be a problem in practice, as most code which uses these names
for its own variables will also continue to work; redefining them in a
local script should not have any effect on either the script or the
Reporting API. One possibility for breakage would be a script that defines,
say, a "Report" object, (unrelated to the Reporting API,) but does so only
if it did not previously exist. In that case, the hypothetical script would
*not* define its own Report, and would presumably attempt to use the
newly-exposed interface object. In order for this to be a real issue, a
script would have to: 1. Use one of these symbol names, down to
capitalization. I suspect that "Report" is the most probable, with the
various ReportBody types being far less likely candidates for collision 2.
Specifically guard against re-defining the symbol, even though it's not
currently platform-exposed anywhere. This would likely only occur if some
initialization code was expected to be run multiple times blindly. (Blink's
web test result page, for instance, uses "Report" as an object name, but
defines it unconditionally, so it will simply shadow the interface object.)


*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No signals

*Other signals*:

Ergonomics

None


Activation

None


Security

None


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?



Debuggability



Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

This is a change to the IDL for these interfaces, and is automatically
supported by all Blink platforms.


Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?Yes

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1122656

Estimated milestones

M110

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5977883141472256

This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKUf6wAHB-3EdgP04%2Bcmhgis3j3M54B%3DASXGtHVJcenDQ%40mail.gmail.com.

Reply via email to