Gecko has a variant of ORB enabled currently in early beta and earlier https://bugzilla.mozilla.org/show_bug.cgi?id=1821682 We had full ORB, but had to relax the rules a bit similarly to what Blink has done, if I understood correctly. And there is also an experiment ongoing.
But I can't recall the details whether Gecko's implementation matches Blink v0.2 exactly (and some folks are on vacation atm so I can't ask right now). -Olli On Tue, Jul 25, 2023 at 6:16 PM Dominic Farolino <[email protected]> wrote: > *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642) >> In implementation. > > > "In implementation" and "No signal" sound a little conflicting. Is the > feature *definitely* being implemented in Firefox? Can we file for a > proper standards signal to be sure? > > Specificationhttps://github.com/whatwg/fetch/pull/1442 > > > It looks like the spec PR here has been dormant for something like ~9 > months. Are there any plans to help drive it to the finish line, > especially given the TODOs listed in the OP? How should we all think about > whatever work might remain there, and possibly deviate from what Chrome > plans on shipping? > > 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) >> > > Just to double check, are we confident that the tests in that directory > assert what the spec PR currently requires? I only ask because the spec has > seemed quiet for a while (as mentioned above) and that makes it easy for > things to accidentally get out of sync. > > On Tue, Jul 25, 2023 at 3: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? >> >> >>> >>> >>>> >>>>>>> >>>>>>> *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/CAL5BFfVY%2BTDQMku-TkjrnkkeDu_%2B7Gf_d1u3UTs-AxZ9SxdXZA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVY%2BTDQMku-TkjrnkkeDu_%2B7Gf_d1u3UTs-AxZ9SxdXZA%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/CAP-uykDddQpLPP%3DehPYSDdTVLi1qxMaOtsU5JXd9H%3DcLJRD5%2Bg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykDddQpLPP%3DehPYSDdTVLi1qxMaOtsU5JXd9H%3DcLJRD5%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -Olli -- 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/CAA%2B07GVEAjLacA63AhVqTQ3N2MfHGoETtEknkzmYcRdBQ%3D7-uw%40mail.gmail.com.
