I've been working on the transition to dict, but failed to revert the initial exposure, which we believed was unlikely to have any real compat issues.
That seems to be wrong, as https://bugs.chromium.org/p/chromium/issues/detail?id=1414463 was filed recently saying that it breaks an enterprise use case. I'm going to revert the original change immediately, but unfortunately we did allow this to ship in M110. I'd appreciate any guidance here from API owners for any additional steps to take to mitigate this; my immediate plan is to revert and merge back to M111, and propose a merge back to M110 for the next point release. On Fri, Nov 25, 2022 at 1:51 PM Ian Clelland <iclell...@chromium.org> wrote: > > > On Fri, Nov 25, 2022 at 12:03 PM Manuel Rego Casasnovas <r...@igalia.com> > wrote: > >> WebKit has been doing some work implementing the Reporting API: >> https://bugs.webkit.org/show_bug.cgi?id=189365 >> >> Do we know their plans regarding this topic? Should we ask for signals? >> > > Thanks Rego -- > > The last time I heard, Chris Dumez had been working on an implementation, > but it didn't include ReportingObserver. I'll reach out to see if that's > changed, and I suppose it can't hurt to file for an official signal, now > that they've implemented that as a repository. > > Ian > > >> Cheers, >> Rego >> >> On 25/11/2022 15:39, Rick Byers wrote: >> > On Fri, Nov 25, 2022 at 9:27 AM Ian Clelland <iclell...@chromium.org >> > <mailto:iclell...@chromium.org>> wrote: >> > >> > >> > >> > On Fri, Nov 25, 2022 at 1:54 AM Domenic Denicola >> > <dome...@chromium.org <mailto:dome...@chromium.org>> wrote: >> > >> > >> > >> > On Fri, Nov 25, 2022, 14:53 Yoav Weiss <yoavwe...@chromium.org >> > <mailto:yoavwe...@chromium.org>> wrote: >> > >> > >> > On Fri, Nov 25, 2022 at 5:50 AM Domenic Denicola >> > <dome...@chromium.org <mailto:dome...@chromium.org>> wrote: >> > >> > Note that in the past I've suggested these not be >> > interfaces at >> > all: https://github.com/w3c/reporting/issues/216 >> > <https://github.com/w3c/reporting/issues/216> . As far >> > as I can tell that issue is still open, and it would >> > have been better to resolve it by making everything use >> > dictionaries (or even just non-dictionary objects, like >> > several specs do today) instead of creating new >> > interfaces against proposed W3C TAG Design Principles >> > <https://github.com/w3ctag/design-principles/issues/11 >> >. >> > >> > >> > Thanks Domenic. Turning those into dictionaries does sound >> > appealing. Let's wait to hear what Ian says. >> > >> > >> > >> > Also that there is no spec for several of these >> > interfaces (at least CoopAccessViolationReportBody, >> > possibly others). So I think there's considerable >> > interop risk. >> > >> > >> > That interop risk is orthogonal to whether we expose those >> > interfaces or not, right? Not saying it shouldn't be fixed, >> > just that the risk exists already. >> > >> > >> > I don't think it's orthogonal. Once the interfaces are exposed, >> > they're much easier to depend on the existence of, and given >> > that there is no spec for their shape or behavior, such >> > dependence seems like an Interop risk. >> > >> > >> > Most of these are spec'd: >> > Report: https://w3c.github.io/reporting/#ref-for-dom-report >> > <https://w3c.github.io/reporting/#ref-for-dom-report> >> > ReportBody: https://w3c.github.io/reporting/#reportbody >> > <https://w3c.github.io/reporting/#reportbody> >> > CSPViolationReportBody: >> https://www.w3.org/TR/CSP3/#cspviolationreportbody < >> https://www.w3.org/TR/CSP3/#cspviolationreportbody> >> > DeprecationReportBody: >> https://wicg.github.io/deprecation-reporting/#deprecationreportbody < >> https://wicg.github.io/deprecation-reporting/#deprecationreportbody> >> > InterventionReportBody: >> https://wicg.github.io/intervention-reporting/#interventionreportbody < >> https://wicg.github.io/intervention-reporting/#interventionreportbody> >> > >> > CoopAccessViolationReportBody and DocumentPolicyViolationReportBody >> > are not. CrashReportBody *is*, though not usefully, as it's not >> > observable. >> > >> > >> > We definitely shouldn't be exposing interface objects that aren't >> > spec'd. Thanks for catching this Domenic. >> > >> > I'm definitely not against turning these into WebIDL dictionaries, >> > as they don't actually have any behaviour - they're just a >> > collection of named data. They were originally defined as >> > interfaces, I believe, in order to spec the constraints on the names >> > and types of their data members. Using plain objects at the time >> > would have made that more difficult. As I understand it, WebIDL >> > dictionaries do not expose any symbols on the global namespace, so >> > that would remove the compatibility concern. >> > >> > I'd like the API Owners to reconsider their LGTMs in >> > light of these unresolved discussions. At the very >> > least, I think at TAG review is warranted for this, as >> > there are architectural implications here. But fixing >> > the spec situation would be even better. >> > >> > >> > I'll revert the change for now, and take a pass at changing the >> > specs involved. >> > >> > Thanks for weighing in, Domenic! >> > >> > >> > Saying this intent is on hold >> > until https://github.com/w3c/reporting/issues/216 >> > <https://github.com/w3c/reporting/issues/216> is resolved one way or >> the >> > other makes sense to me. Let's take the design debate there. I have some >> > additional questions / concerns but blink-dev isn't the right forum for >> > API design discussions. >> > >> > >> > On Thursday, November 24, 2022 at 3:01:12 PM UTC+9 Yoav >> > Weiss wrote: >> > >> > LGTM3 >> > >> > On Wed, Nov 23, 2022 at 11:28 PM Chris Harrelson >> > <chris...@chromium.org >> > <mailto:chris...@chromium.org>> wrote: >> > >> > LGTM2 >> > >> > On Wed, Nov 23, 2022, 4:14 PM Rick Byers >> > <rby...@chromium.org >> > <mailto:rby...@chromium.org>> wrote: >> > >> > Thanks for doing this analysis. According to >> > our guidelines >> > < >> https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.4k9u8ddizqrq> >> this >> is in the low risk range of <0.001% of pages in HTTP Archive. Personally I >> think we should just go for it, but be prepared to revert (and rename the >> interface instead) if we get even a single bug report in beta. LGTM1 >> > >> > On Wed, Nov 23, 2022 at 4:50 PM Ian Clelland >> > <iclell...@chromium.org >> > <mailto:iclell...@chromium.org>> wrote: >> > >> > So I've run through HTTPArchive with >> > these queries (shown for desktop, mobile >> > is analogous): >> > >> > SELECTAPPROX_COUNT_DISTINCT(pageid) >> > FROM >> > >> `httparchive.summary_requests.2022_10_01_desktop` AS REQ >> > JOIN >> > >> `httparchive.response_bodies.2022_10_01_desktop` AS RESP on REQ.url = >> RESP.url >> > WHERE ( >> > REQ.resp_content_type = >> > 'application/javascript' OR >> > REQ.resp_content_type = >> 'text/javascript' OR >> > REQ.resp_content_type = >> > 'application/html' OR >> > REQ.resp_content_type = 'text/html') >> > AND ( >> > REGEXP_CONTAINS(RESP.body, >> > r"\bwindow\.Reporting\b") OR >> > REGEXP_CONTAINS(RESP.body, >> > r"\bself\.Reporting\b")); >> > >> > >> > And found 161 pages on desktop (out of >> > ~10M pages), and 185 on mobile (of >> > ~15M). (For comparison, replacing >> > "Report" with "ReportingObserver", >> > yields ~123k pages on desktop referring >> > to that symbol) >> > >> > Coalescing distinct resource URLs in >> > this case (as many may be from the same >> > third-party library) yields just 110 >> > URLs on mobile, including many clearly >> > repeated resources hosted on different >> > subdomains of kindful.com >> > <http://kindful.com>, and >> > several named simply '/js/common.js': >> > >> > >> https://cookerevivals.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> < >> https://cookerevivals.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> > >> > >> https://atlast.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> < >> https://atlast.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> > >> > >> https://indushospitalca.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> < >> https://indushospitalca.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> > >> > >> https://stridereducationfoundation-bloom.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> < >> https://stridereducationfoundation-bloom.kindful.com/assets/application-b1789711faae06cb6b1679d08f18c4ee8bfde712fa6375641c5e38fca8231494.js >> > >> > (And many more; these ones >> > unconditionally overwrite Report) >> > >> > >> https://tesotunes.com/js/common.js?version=2.1.5.8-beta-22 < >> https://tesotunes.com/js/common.js?version=2.1.5.8-beta-22> >> > http://arabgramz.com/js/common.js?x=37 >> > <http://arabgramz.com/js/common.js?x=37 >> > >> > >> https://www.yavedo.com/js/common.js?x=55 >> > < >> https://www.yavedo.com/js/common.js?x=55> >> > https://shakulive.com/js/common.js?x44 >> > <https://shakulive.com/js/common.js?x44 >> > >> > (These ones do check for Report's >> > existence, and use "window.Report || ( >> > window.Report = {} );" before defining >> > new methods. This will also continue to >> > work, but will add new methods to the >> > interface object, rather than the >> > presumed empty dict.) >> > >> > On Wed, Nov 23, 2022 at 12:48 PM Rick >> > Byers <rby...@chromium.org >> > <mailto:rby...@chromium.org>> wrote: >> > >> > >> > On Wed, Nov 23, 2022 at 12:22 PM >> > Yoav Weiss <yoavwe...@chromium.org >> > <mailto:yoavwe...@chromium.org>> >> wrote: >> > >> > >> > On Wed, Nov 23, 2022 at 6:13 PM >> > Ian Clelland >> > <iclell...@chromium.org >> > <mailto:iclell...@chromium.org >> >> >> > 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 >> > <mailto:dome...@google.com> 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 < >> https://github.com/whatwg/webidl/issues/350> renames "NoInterfaceObject" >> to "LegacyNoInterfaceObject" >> > >> https://github.com/whatwg/webidl/issues/365 < >> 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 < >> https://github.com/w3c/reporting/pull/173>, after >> https://github.com/whatwg/webidl/pull/423 < >> 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 < >> https://github.com/whatwg/webidl/issues/1236> to hopefully have that >> captured somewhere. >> > >> > On Wed, Nov 23, 2022 at >> > 11:18 AM Rick Byers >> > <rby...@chromium.org >> > <mailto:rby...@chromium.org>> >> 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 >> > <yoavwe...@chromium.org >> > <mailto: >> yoavwe...@chromium.org>> 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 >> > < >> iclell...@chromium.org <mailto:iclell...@chromium.org>> wrote: >> > >> > >> > Contact >> > emails >> > >> > >> iclell...@chromium.org <mailto:iclell...@chromium.org> >> > >> > >> > >> Specification >> > >> > >> https://w3c.github.io/reporting/#idl-index < >> https://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 >> > >> component >> > >> > >> Blink>ReportingObserver < >> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EReportingObserver >> > >> > >> > >> > TAG >> review >> > >> > >> > >> > TAG >> > review >> > status >> > >> > Not 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 < >> 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 < >> 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 >> > >> blink-dev+unsubscr...@chromium.org <mailto: >> blink-dev+unsubscr...@chromium.org>. >> > 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 >> > >> blink-dev+unsubscr...@chromium.org <mailto: >> blink-dev+unsubscr...@chromium.org>. >> > 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 >> > blink-dev+unsubscr...@chromium.org >> > <mailto:blink-dev+unsubscr...@chromium.org >> >. >> > To view this discussion on the web visit >> > >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8pXY9nUDxRwXTheVUCf0A81cZyfJLE7WDA%2B4%3Dqf-DiJQ%40mail.gmail.com >> < >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8pXY9nUDxRwXTheVUCf0A81cZyfJLE7WDA%2B4%3Dqf-DiJQ%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 blink-dev+unsubscr...@chromium.org >> > <mailto:blink-dev+unsubscr...@chromium.org>. >> > To view this discussion on the web visit >> > >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9QQoXMpH8ex%3DYJW0-3YATGXQj%3DZSuYWNXP5Pi5ciCpMg%40mail.gmail.com >> < >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9QQoXMpH8ex%3DYJW0-3YATGXQj%3DZSuYWNXP5Pi5ciCpMg%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXJCp-b0z-XDy_f1C48iksnP5k9rVPmJwc9rO6ZSnTHrXQ%40mail.gmail.com.
