I assume it's this use counter:
https://chromestatus.com/metrics/feature/timeline/popularity/5203
(SharedWorkerScriptUnderServiceWorkerControlIsBlob). It doesn't seem to
have picked up any usage, which is either good or bad...
yyanagisawa, do you know which it is?
/Daniel
On 2024-11-26 10:00, Domenic Denicola wrote:
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
<https://w3c.github.io/ServiceWorker/#control-and-use-worker-client>
Summary
According to
https://w3c.github.io/ServiceWorker/#control-and-use-worker-client
<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
<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
<https://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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9fn%2B7i8%3DOh72j43C7nVeG4%3D850zaqZShgiaAhhTVBCpA%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ee65472-2477-4911-9309-882dfa0dced3%40gmail.com.
