These numbers sound good to me. I have no concerns with continuing the rollout, and you don't need any more approvals from us to continue.
Thanks for reporting back. On Tue, Oct 24, 2023 at 8:41 AM 'Daniel Vogelheim' via blink-dev < [email protected]> wrote: > Hello all, it's been a while. > > On Wed, Aug 16, 2023 at 7:23 PM Chris Harrelson <[email protected]> > wrote: > >> LGTM1 to turn it on in M118 beta and report back to this group about use >> counter results/bugs reported on beta before it reaches stable. >> > > As requested, I have added use counters to measure ORB-blocked resources > on elements (script and img/video/media) with event handlers. On current > stable, I get this: (source > <https://uma.googleplex.com/p/chrome/timeline_v2?sid=064bd3472f5dfd2a92f8d34049e5848e> > ) > > - 0.006% of page loads have a script or media element with an event > handler (and thus potential compatibility impact from this change; although > we don't know what the impact would be) > - 0.0075 % of page loads have a script or media element without any event > handlers (and thus guaranteed without compatibility impact from this change) > - The majority of pages with any event handler seem to have both handlers > - onload and onerror - set. > > I'll note that the sum of those (with any + without any) are much lower > than the numbers I previously reported in this thread. I believe that's > because of 1, here we only count specific HTML elements (but not e.g. the > ping attribute on links), and 2, the carveout for fetch()-initiated > requests. The previously reported metric counted ORB-related blocks across > all page-initiated responses, regardless of whether it might be > script-visible or not. > > Daniel > > > On Fri, Aug 11, 2023 at 2:50 AM 'Daniel Vogelheim' via blink-dev < >> [email protected]> wrote: >> >>> On Wed, Jul 26, 2023 at 11:29 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> On Tue, Jul 25, 2023 at 6:48 PM Daniel Vogelheim <[email protected]> >>>> wrote: >>>> >>>>> On Tue, Jul 25, 2023 at 9:10 AM Yoav Weiss <[email protected]> >>>>> wrote: >>>>> >>>>>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Contact [email protected] >>>>>>>>>>> >>>>>>>>>>> Specificationhttps://github.com/whatwg/fetch/pull/1442 >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin >>>>>>>>>>> Read Blocking (CORB - >>>>>>>>>>> https://chromestatus.com/feature/5629709824032768). CORB and >>>>>>>>>>> ORB are both heuristics that attempt to prevent cross-origin >>>>>>>>>>> disclosure of >>>>>>>>>>> “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's >>>>>>>>>>> second >>>>>>>>>>> step towards a full ORB implementation. ORB specifies error >>>>>>>>>>> handling for >>>>>>>>>>> blocked resources differently from CORB: ORB raises network errors, >>>>>>>>>>> while >>>>>>>>>>> CORB injects an empty response. ORB "v0.1" still used CORB-style >>>>>>>>>>> response >>>>>>>>>>> injection. This change brings our implementation more in line with >>>>>>>>>>> the ORB >>>>>>>>>>> proposal, by changing the error handling of all fetches (except when >>>>>>>>>>> initiated by a script) to be compliant with ORB. We've made a >>>>>>>>>>> carve-out for >>>>>>>>>>> script-initiated fetches (where we retain CORB behaviour for now) >>>>>>>>>>> to limit >>>>>>>>>>> compatibility risk. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Blink componentInternals>Sandbox>SiteIsolation >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ESandbox%3ESiteIsolation> >>>>>>>>>>> >>>>>>>>>>> TAG reviewNone >>>>>>>>>>> (A TAG review of a particular aspect happened in: >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/618) >>>>>>>>>>> >>>>>>>>>>> TAG review statusNot applicable >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> This release does not modify blocking behaviour, but only how a >>>>>>>>>>> blocked resource is represented. Ideally, this change shouldn't >>>>>>>>>>> break any >>>>>>>>>>> existing code since any resource that loads (or gets blocked) >>>>>>>>>>> before will >>>>>>>>>>> continue to do so after. However, it is possible to distinguish >>>>>>>>>>> between the >>>>>>>>>>> different types of error handling, and it may well happen that an >>>>>>>>>>> application inadvertently relies on blocked resources "succeeding". >>>>>>>>>>> In our >>>>>>>>>>> examinations so far, this chiefly concerns fetches using the >>>>>>>>>>> `fetch()` API, >>>>>>>>>>> where blocking with a network error results in a failed promise >>>>>>>>>>> (instead of >>>>>>>>>>> a success with an empty response). For this reason, we have carved >>>>>>>>>>> out >>>>>>>>>>> script-initiated fetches from "v0.2" and intend to handle them at a >>>>>>>>>>> later >>>>>>>>>>> date. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, so how would this change be web exposed? Are there scenarios >>>>>>>>>> where an "error" event would now fire instead of a "load" event? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, exactly. If a site is waiting for an onload event - despite >>>>>>>>> not really caring about whether the load is actually meaningful, >>>>>>>>> since it >>>>>>>>> currently already loads empty - then it would see a behavioural >>>>>>>>> change. >>>>>>>>> >>>>>>>>> >>>>>>>> Do we have stats on how often that would happen? (e.g. how often an >>>>>>>> onload event fires on an ORB empty resource?) >>>>>>>> >>>>>>> >>>>>>> No. I didn't realize I could measure onload events firing >>>>>>> specifically for ORB-blocked resources. So I unfortunately don't have >>>>>>> that >>>>>>> data. >>>>>>> >>>>>>> The number of page views with any CORB/ORB-blocked resource in it >>>>>>> hovers around 0.35% of page loads. That should provide an upper bound, >>>>>>> but >>>>>>> doesn't tell us how many of them care about the onload/onerror events. >>>>>>> >>>>>> >>>>>> One way to avoid a 2 months delay while we're waiting on data could >>>>>> be to add the use counters + a base feature and go ahead with a removal, >>>>>> but turning it off if we see that the actual breakage exceeds some >>>>>> threshold. >>>>>> Thoughts? >>>>>> >>>>> >>>>> Turning this on via server-side experiments (and thus being able to >>>>> turn it off quickly on problem reports) is easy to do. It might make sense >>>>> to have it enabled on beta 50/50 for a while, to see whether anyone >>>>> notices. >>>>> >>>>> I find it surprisingly hard to implement the use counters: The code >>>>> that knows the network status (and thus _why_ a response might be empty) >>>>> is >>>>> separated by several layers from the code that knows the element and >>>>> whether it has any event handlers. :-/ >>>>> >>>> >>>> I agree that piping that information over from the browser to the >>>> renderer would be an overkill (and may have security implications on >>>> its own). In that case, a careful Finch may be sufficient. >>>> One last thought - maybe it's possible to report the information to UKM >>>> from both sides of the code, and join it at analysis time? (if that's not >>>> too complex) >>>> >>> >>> I've now landed the usecounter CL. What I'd like to do is: Enable the >>> feature on beta now and wait for numbers to arrive from the usecounters. >>> This would give us two signals on compatibility. >>> >>> According to the current schedule, the counters will make it into 118. >>> >>> >>> >>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) In >>>>>>>>>>> implementation. >>>>>>>>>>> >>>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/64) >>>>>>>>>>> >>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>> >>>>>>>>>>> *Other signals*: >>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/618 >>>>>>>>>>> >>>>>>>>>>> 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? >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>> Yes >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ?Yes (https://wpt.fyi/results/fetch/orb) >>>>>>>>>>> >>>>>>>>>>> Flag name on chrome://flags >>>>>>>>>>> >>>>>>>>>>> Finch feature nameOpaqueResponseBlockingV02 >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome?False >>>>>>>>>>> >>>>>>>>>>> Tracking bug >>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1463725 >>>>>>>>>>> >>>>>>>>>>> Estimated milestones >>>>>>>>>>> Shipping on desktop 117 >>>>>>>>>>> DevTrial on desktop 115 >>>>>>>>>>> Shipping on Android 117 >>>>>>>>>>> DevTrial on Android 115 >>>>>>>>>>> Shipping on WebView 117 >>>>>>>>>>> >>>>>>>>>>> Anticipated spec changesNone >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> https://chromestatus.com/feature/5166834424217600 >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/ScjhKz3Z6U4 >>>>>>>>>>> >>>>>>>>>>> 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/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPPNdN%3DO0j0MhcfudkBtMoYnELhVRJ5nLftB8c1T1UdwbQ%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/CALG6KPMpGi0K71%3DF8i4SjKt_1RuVnpAiavv1mArDO--rzLSSwA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMpGi0K71%3DF8i4SjKt_1RuVnpAiavv1mArDO--rzLSSwA%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/CALG6KPOi_sOLKazGH-2fno%3DQXegL7oO6RyDe4c5zudWro3DGdA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPOi_sOLKazGH-2fno%3DQXegL7oO6RyDe4c5zudWro3DGdA%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/CAOMQ%2Bw97-vAPe_n47WBC2YQ%3D_uTmBMnwSiR7bY7visPY7MYVNQ%40mail.gmail.com.
