On Tue, Nov 26, 2024 at 4:20 PM Yoshisato Yanagisawa <yyanagis...@google.com> wrote:
> Thanks for the response, > Let me reply inline. > > 2024年11月19日(火) 15:56 Domenic Denicola <dome...@chromium.org>: > >> >> >> On Tue, Nov 19, 2024 at 2:15 PM Yoshisato Yanagisawa < >> yyanagis...@google.com> wrote: >> >>> >>> >>> 2024年11月18日(月) 17:02 Domenic Denicola <dome...@chromium.org>: >>> >>>> >>>> >>>> On Friday, November 15, 2024 at 9:14:09 AM UTC+9 Chromestatus wrote: >>>> >>>> Contact emails yyanagis...@google.com >>>> >>>> Explainer None >>>> >>>> Specification https://w3c.github.io/ServiceWorker/#control-and- >>>> use-worker-client >>>> >>>> Summary >>>> >>>> According to https://w3c.github.io/ServiceWorker/#control-and- >>>> use-worker-client, workers should inherit controllers for the blob >>>> URL. However, existing code allows only dedicated workers to inherit the >>>> controller, and shared workers do not inherit the controller. This is the >>>> fix to make Chromium behavior adjust to the specification. An enterprise >>>> policy SharedWorkerBlobURLFixEnabled is available to control this feature. >>>> >>>> >>>> Blink component Blink>Workers >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWorkers> >>>> >>>> TAG review None >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> This is a change to make the Chromium behavior aligned with the >>>> specification, there should not be an interoperability issue. However, >>>> there is a compatibility issue from the past Chromium. If a blob URL is >>>> used for a SharedWorker script and a controller for the URL is mattered, >>>> there is a behavior change because this change makes a controller >>>> inherited. An enterprise policy was added to allow enterprise customers to >>>> preserve the past Chromium behavior. >>>> >>>> Do you have any metrics on how many page loads this change might >>>> impact? An enterprise policy seems like a good idea, but if the number of >>>> page loads is high, we might want to consider a deprecation trial or >>>> similar mechanism. >>>> >>>> >>> >>> Yes. The I2S was proposed as the web facing change PSA ( >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/hClP93e4MLk/m/SGXfxOZfAQAJ) >>> before, and I gave up to go with the PSA due to the amount of the case that >>> the blob URL is used as a SharedWorker script URL is too large. >>> I revisited the metrics and saw 10-40% SharedWorker script URLs are blob >>> URL depending on platform. >>> Is it better to go with a deprecation trial? >>> >> >> 10-40% is very high, so yes, we need to consider ways to find an upper >> limit on the danger. >> >> My guess is that most pages will not have their behavior changed, >> because, for example, their service worker JavaScript ignores non-https: >> fetches. The fact that these pages probably work fine in Safari is also >> helpful evidence. >> >> I would suggest two strategies: >> >> - Use UKM or HTTP Archive to examine the top-N sites that trigger >> this UseCounter (maybe N = 20 or so is good). Confirm via code inspection >> or running with the flag flipped or similar techniques that there is no >> compat impact. Publish this data for the API owners to see. >> >> > Sure. > https://chromium-review.googlesource.com/c/chromium/src/+/6049677 to add > UKM and UseCounter. > Let's see the statistics after it is shipped. > Oh, my suggestion was to get data sooner, by using the existing use counter with HTTP archive analysis <https://www.chromium.org/blink/platform-predictability/compat-tools/>. Then you don't have to wait for any code to roll out to stable. > >> - Also do a deprecation trial to allow opting in to the old behavior. >> The UKM/HTTP archive analysis can increase our confidence that the >> breakage >> is low (like, if 0 or 1 out of 20 pages are broken, then the breakage is >> probably <1%). But it cannot give us enough precision to be confident, so >> having the escape hatch of the deprecation trial seems important. >> >> Just let me confirm if my understanding is correct. > Does the deprecation trial mean the origin trial to preserve the legacy > behavior? > We enable the flag by default while starting the origin trial. The site > with the origin trial token can preserve the legacy behavior, right? > Yes, that's the idea! See this link <https://www.chromium.org/blink/launching-features/#deprecation-trial>. I guess the wording there is a bit confusing since you aren't "removing" a feature, but instead changing how an existing feature works. I think it should not matter much though. It is still closer to a deprecation trial than an origin trial. For example, you do not need to write a specification for the behavior that the trial enables, like you would with an origin trial. > > >> I'm sorry that this adds so much process for what is basically a bug fix. >> It is possible there would be other ways to avoid it, for example by >> creating a more precise use counter that detects "changed behavior". (But, >> it is hard to imagine how to write the code for such a use counter... maybe >> something about comparing response bytes??) However my guess is that the >> time and effort of writing that precise use counter is probably more than >> the effort in setting up a deprecation trial. So my advice is to pursue the >> above approach. >> >> >>> >>> >>>> >>>> >>>> *Gecko*: No signal >>>> >>>> >>>> Can you ask Gecko for signals? I am especially curious why they haven't >>>> updated to match the specification. >>>> >>>> >>> >>> Sure. I have filed the mozilla's standard position for it. >>> https://github.com/mozilla/standards-positions/issues/1113 >>> >>> >>>> >>>> >>>> *WebKit*: Shipped/Shipping >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> Ergonomics >>>> >>>> n/a >>>> >>>> >>>> Security >>>> >>>> Since this is adjusting Chromium behavior to specification, there >>>> should not be a security risk from a specification perspective. From the >>>> implementation perspective, this change simply inherits existing >>>> controller. There should not be any additional security risks with this >>>> change. >>>> >>>> >>>> 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? >>>> >>>> Since SharedWorker is not supported on Android yet, there is no risk on >>>> Android WebView. >>>> >>>> >>>> Debuggability >>>> >>>> n/a >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No >>>> >>>> Since SharedWorker is not supported in Android yet, the feature also >>>> does not affect to Android. >>>> >>>> >>>> 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/service-workers/service- >>>> worker/local-url-inherit-controller.https.html Same-origin blob URL >>>> sharedworker should inherit service worker controller. Same-origin blob URL >>>> sharedworker should intercept fetch(). The tests ensure a >>>> ServiceWorkerController is inherited. Due to crbug.com/40364838, >>>> Chromium does not pass the former test. >>>> >>>> >>>> Flag name on about://flags None >>>> >>>> Finch feature name SharedWorkerBlobURLFix >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug https://crbug.com/324939068 >>>> >>>> Estimated milestones Shipping on desktop 133 >>>> >>>> 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). >>>> None >>>> >>>> Link to entry on the Chrome Platform Status https://chromestatus.com/ >>>> feature/5137897664806912?gate=5147843735322624 >>>> >>>> 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. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9fn%2B7i8%3DOh72j43C7nVeG4%3D850zaqZShgiaAhhTVBCpA%40mail.gmail.com.
