On Wed, Nov 23, 2022 at 12:22 PM Yoav Weiss <[email protected]> wrote:
> > On Wed, Nov 23, 2022 at 6:13 PM Ian Clelland <[email protected]> > wrote: > >> Well, that is exactly the situation outlined as a risk. I'm still running >> some HTTPArchive queries, but didn't immediately see much there. >> >> I expect that +Domenic Denicola <[email protected]> may have more >> context on the changes here, but my understanding is that WebIDL has been >> moving towards this for some time. >> >> The issues I'm aware of are on WebIDL: >> https://github.com/whatwg/webidl/issues/350 renames "NoInterfaceObject" >> to "LegacyNoInterfaceObject" >> https://github.com/whatwg/webidl/issues/365 starts mandating the use of >> "Exposed" in all interfaces >> >> Reporting specifically was updated in 2019, with >> https://github.com/w3c/reporting/pull/173, after >> https://github.com/whatwg/webidl/pull/423 made Exposed mandatory. >> > > Is it possible to rename these exposed interfaces to something less > generic, that's less likely to collide? > Since it's not exposed today, nobody should be depending on the name. So I'm sure we could. But I'd like to understand why we should expose it at all. I tried digging through the history of discussions on this topic and the contents of the WebIDL spec but couldn't get clarity on what the thinking has been. I filed https://github.com/whatwg/webidl/issues/1236 to hopefully have that captured somewhere. On Wed, Nov 23, 2022 at 11:18 AM Rick Byers <[email protected]> wrote: >> >>> I did a quick GitHub search and quickly found this >>> <https://github.com/xuehuibo/MobileQueryPlatform/blob/master/MobileQueryPlatform/MobileQueryPlatform/Views/Home/ReportMenu.cshtml>: >>> :-( >>> >>> if (window.Report == undefined) { >>> Tools.Namespace.register("window.Report"); >>> } >>> >>> And then a bunch of downstream code expecting to build stuff up on >>> window.Report. I didn't try to find out where or how much this is used, but >>> it's certainly not promising. >>> >>> Where is this decision to expose all interface objects by default coming >>> from? Are we sure it's the right thing for the web when the global >>> namespace is shared between the platform and application code? >>> >>> Sorry Ian, I know I said I thought this should be a simple one :-). If >>> we have data that it looks very rare, then I'm still happy to approve. I'm >>> just wondering now about the bigger picture of this class of changes. >>> >>> Rick >>> >>> On Wed, Nov 23, 2022 at 9:52 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> As this is not actually a feature, but a spec alignment effort, I think >>>> it makes sense to skip TAG reviews and vendor positions for this. >>>> >>>> I'm slightly concerned about `Report` collisions. Would you be able to >>>> run a quick HTTPArchive scan for "window.Report" and "self.Report" and see >>>> what that gives? ("var Report" would just unconditionally override it, so >>>> that's not an issue) >>>> >>>> On Wed, Nov 23, 2022 at 2:55 PM Ian Clelland <[email protected]> >>>> wrote: >>>> >>>>> 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 bug >>>>> https://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 >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKUf6wAHB-3EdgP04%2Bcmhgis3j3M54B%3DASXGtHVJcenDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> 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/CAL5BFfV3b3BnY26B6tuGtFFYRm-K5P0U6b5_giLgB1h6PeK7ag%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV3b3BnY26B6tuGtFFYRm-K5P0U6b5_giLgB1h6PeK7ag%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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/CAFUtAY8V5cy7fdtUYS%3DZLgGj-7-eOD9jwM03p1aJCqW0S_ofFA%40mail.gmail.com.
