The UMA and use count is recorded in the following code:
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/service_worker/service_worker_main_resource_loader_interceptor.cc;l=132;drc=a5bdf0106da2489011a9846f280f29872258a8dd
The usecount is set if the request URL is blob, and the navigation
handle has the service worker client and the client has a controller.
As you can see, we record UMA just before the usecount, which records
the number of the blob URL and non-blob URL cases. Since we can see
non negligible IsBlob true cases, I assumed that the usecount is
broken. Note that it just says that SharedWorker is created under a
page controlled by a ServiceWorker. We are not sure if the
change brings a visible difference to the SharedWorker.
Considering what I have mentioned before, I should have added the
metrics like:
* clients.matchAll() or match() look up the SharedWorker where the
SharedWorker script is a blob URL.
* SharedWorker fetches other resources while the SharedWorker script
is a blob URL.
They should be the case affected by this change. Is there anything
else I missed?
2025年3月11日(火) 4:38 Chris Harrelson <chris...@chromium.org>:
Were you able to manually
verify the SharedWorkerScriptUnderServiceWorkerControlIsBlob use
counter hits with a test page? If so, I suppose it's possible no
one is using this combination of features? Do you know of any site
at all that does so?
On Wed, Mar 5, 2025 at 5:32 PM 'Yoshisato Yanagisawa' via
blink-dev <blink-dev@chromium.org> wrote:
Sorry for not working on this for a long time.
Considering what I am seeing with other statistics, I am
assuming the use count is wrong.
Last Dec, I started to do analysis on
https://chromestatus.com/metrics/feature/timeline/popularity/5,
however it is really cumbersome to find a SharedWorker script
in obfuscated JavaScript and the analysis did not go well.
As far as I understand, SharedWorker behavior change may happen:
1. if SharedWorker `fetch()`, and the request is intercepted
by the ServiceWorker.
2. or if the ServiceWorker tries to look up the SharedWorker
as its client, and postMessage().
I did not follow the 1 case, but as far as I checked 50 sites
from the beginning listed with
https://chromestatus.com/metrics/feature/timeline/popularity/5,
I could not find the case like 2.
Therefore, I assume the risk is quite low.
If the risk matters, I can also do the deprecation study.
2025年3月5日(水) 23:14 Daniel Bratell <bratel...@gmail.com>:
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/CAPNB-6XY_%3DTj%3DWyi%3Dhh%3D-wny5beHqNAT7G_ObTR4eof-duXNdQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6XY_%3DTj%3DWyi%3Dhh%3D-wny5beHqNAT7G_ObTR4eof-duXNdQ%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/CAPNB-6WLWGs7NLckDw5v7XMy1WX6BefKunvNJQJ0wskrGFs0iQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6WLWGs7NLckDw5v7XMy1WX6BefKunvNJQJ0wskrGFs0iQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
