I talked to Keita and Youenn (Apple WebKit) last week at TPAC.
Since WebKit already shipped the new names (in Safari 27 AFAICT), I
think our best bet is to do the following:
* Implement the new shape and expose it to the web (potentially for a
brief window)
* Move the usecounter implementation to the getter of the attributes,
rather than simple enumeration. Do that for both the old and new shapes.
* Gather data as soon as this hits stable.
The data we'd gather can then guide a decision on which shape should
stick around.
On Wednesday, September 16, 2026 at 5:02:58 PM UTC+2 Alex Russell wrote:
Any progress?
On Tuesday, August 18, 2026 at 6:02:08 AM UTC-7 Keita Suzuki wrote:
Hi Alex,
Thanks for checking in and sorry for the late response.
We are still actively discussing the next steps on a seperate
thread, and will get back to you as soon as we reach a conclusion.
Thanks so much.
Best,
Keita
On Tue, Aug 18, 2026 at 6:38 AM Alex Russell
<[email protected]> wrote:
Any progress? Or should we archive this Intent?
Best,
Alex
On Monday, June 15, 2026 at 11:37:54 AM UTC-7 Alex Russell
wrote:
Have there been updates related to any of the data
Mike asked for here?
Best,
Alex
On Sunday, April 19, 2026 at 7:35:42 AM UTC-7 Mike
Taylor wrote:
On 4/16/26 2:31 a.m., Yoav Weiss (@Shopify) wrote:
Can we align the spec to the implementation,
rather than the other way around?
The current names seem fine at first glance..
On Fri, Apr 17, 2026 at 2:24 AM Yoshisato
Yanagisawa <[email protected]> wrote:
Hi Yoav and Rick,
Thank you for raising this point. I believe
there is a misunderstanding regarding the
background that necessitates this Intent to
Ship.
The initial Intent to Ship
<https://groups.google.com/a/chromium.org/g/blink-dev/c/NqI9QfefGbo/m/RXADtpfRCQAJ>
for
this feature already included a link to the
specification's Pull Request
<https://github.com/w3c/resource-timing/pull/415/commits>,
which defined the attributes as
`workerMatchedRouterSource` and
`workerFinalRouterSource`. Unfortunately, our
team, including the authors and reviewers,
overlooked the naming mismatch between the
specification and the Chromium code when the
feature was shipped. This oversight led to
the release of the non-compliant fields
(`workerMatchedSourceType` and
`workerFinalSourceType`).
The root cause of the inconsistency was not a
subsequent spec discussion in WebPerfWG (as
seen in the 2024
<https://docs.google.com/document/d/1lhtCeXknwsoVzzMslJmXlYzjgZa0LE0W-ZP3UL8D7to/edit?tab=t.0#heading=h.t8b2j8fdt60u>
and 2025
<https://docs.google.com/document/d/1Yw38B6y4NIioBQtc2tyoCSZrf_F1gi4jI1vB7pLFM0w/edit?tab=t.0#heading=h.3kfawsdwn1ds>
<https://docs.google.com/document/d/1Yw38B6y4NIioBQtc2tyoCSZrf_F1gi4jI1vB7pLFM0w/edit?tab=t.0#heading=h.3kfawsdwn1ds>
meeting minutes). Instead, the issue appears
to have originated from an internal naming
convention within Chromium's implementation.
Specifically, internal usage of the `
<https://chromium-review.git.corp.google.com/c/chromium/src/+/5297034/4/services/network/public/mojom/service_worker_router_info.mojom>ServiceWorkerRouterSourceType`
<https://chromium-review.git.corp.google.com/c/chromium/src/+/5297034/4/services/network/public/mojom/service_worker_router_info.mojom>
enum (a successor to the SourceType
<https://chromium-review.git.corp.google.com/c/chromium/src/+/4547028/20/third_party/blink/public/common/service_worker/service_worker_router_rule.h>
used in older code) seems to have led the
implementation to incorrectly apply the Type
suffix. This was the source of the code
diverging from the specification's proposed
notation, which was defined early in the
process (in this GitHub Issue Comment
<https://github.com/WICG/service-worker-static-routing-api/issues/19#issuecomment-1899471136>).
Therefore, any search for a specification
discussion that /changed/ the name after the
I2S approval will not be fruitful, as the
spec name was intended to be compliant from
the beginning.
I sincerely apologize for this internal
naming inconsistency and the resulting need
for this follow-up Intent to Ship to align
Chromium with the finalized specification.
Regarding Rick's questions:
* *What signals do we have from other
implementors in terms of which name
they've shipped or prefer to ship?*
The naming mismatch was discovered by a
vendor from another browser.
This is helpful to know, but doesn't quite get at
the core concern of the question. Has another
browser/implementer shipped this API with the
specced name? Or is someone about to ship the API,
and that's how they noticed?
Having WebKit and Mozilla vendor positions would
have helped answer this
If answer to either question is "no", I think the
best path forward is what Yoav suggests: we should
make the spec match the shipping implementation.
It's an unfortunate mistake, but it took about a
year for anybody to notice it, and the usage
numbers suggest developers are able to use it
as-is (to Yoav's point that the current names seem
fine).
* *What is the compat risk (e.g.,
UseCounter) of the APIs we've already
shipped?*
The current UseCounter metrics show
approximately 5% usage. However, this
count may be inflated because developers
often list all attributes in a
performance entry, so I doubt the actual
number of users depending on the
non-compliant fields is that high.
o workerMatchedSourceType
https://chromestatus.com/metrics/feature/timeline/popularity/5117
<https://chromestatus.com/metrics/feature/timeline/popularity/5117>
o WorkerFinalSourceType
https://chromestatus.com/metrics/feature/timeline/popularity/5118
<https://chromestatus.com/metrics/feature/timeline/popularity/5118>
5% is very, very high. I assume we don't have a
way to know if sites are depending on these
fields, right (presumably the info is used by
backend systems, so we can't know what would break
or not)?
Thanks,
Yoshisato
2026年4月16日(木) 0:17 Rick Byers
<[email protected]>:
In particular the question is whether
we're better off trying to change the
spec to match what we've shipped, or
change what we've shipped to match the
spec. To resolve this I think we need to
know:
* What signals do we have from other
implementors in terms of which name
they've shipped or prefer to ship?
* What is the compat risk (eg.
UseCounter) of the APIs we've already
shipped? If the usage is already high
then it's unlikely we can unship it,
so we should evaluate the compat risk
before deciding to embark on a rename.
Thanks,
Rick
On Thu, Apr 9, 2026 at 1:42 AM Yoav Weiss
(@Shopify) <[email protected]> wrote:
It looks like the API owners accepted
the interop risk when approving
<https://groups.google.com/a/chromium.org/g/blink-dev/c/NqI9QfefGbo/m/RXADtpfRCQAJ?utm_medium=email&utm_source=footer>
this to ship before the PRs landed.
Can you point us to the spec
discussion that led to the name change?
On Thu, Apr 9, 2026 at 4:11 AM Keita
Suzuki <[email protected]> wrote:
*Contact emails*
[email protected],
[email protected]
<mailto:[email protected]>,
[email protected]
<mailto:[email protected]>
*Specification*
https://github.com/w3c/resource-timing/pull/415
<https://github.com/w3c/resource-timing/pull/415>
*Summary*
Adds the
`workerMatchedRouterSource` and
`workerFinalRouterSource`
attributes to the Resource Timing
and Navigation Timing APIs. These
attributes allow developers to
identify which Service Worker
Static Router rule was matched
and the final source used for the
request. Note on Deprecation:
This change focuses exclusively
on adding the spec-compliant
fields. We will be sending a
separate Intent to Deprecate
(I2D) for the existing
non-compliant fields
(`workerMatchedSourceType` and
`workerFinalSourceType`) once we
have gathered sufficient usage
data from our UseCounters.
*Blink component*
Blink>ServiceWorker
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22>
*Web Feature ID*
resource-timing
<https://webstatus.dev/features/resource-timing>
*Motivation*
The original field names
(`workerMatchedSourceType` and
`workerFinalSourceType`) were
introduced during the
experimental phase and used
throughout the Origin Trial
(M131–M139) . However, the
specification has since settled
on the names
`workerMatchedRouterSource` and
`workerFinalRouterSource` to be
more descriptive and consistent
with the broader API. Renaming
these fields is critical for
ensuring that Chromium remains
spec-compliant and provides a
stable, interoperable interface
for web developers.
*Initial public proposal*
/No information provided/
*TAG review*
/No information provided/
*TAG review status*
Issues addressed
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
/No information provided/
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/Other signals/:
*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. This change is purely
additive (adding the new fields)
and does not change the behavior
of existing APIs in a way that
would break WebView-based
applications
*Debuggability*
/No information provided/
*Will this feature be supported
on all six Blink platforms
(Windows, Mac, Linux, ChromeOS,
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
*Flag name on about://flags*
/No information provided/
*Finch feature name*
/No information provided/
*Non-finch justification*
/No information provided/
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Availability expectation*
Feature is available on Web
Platform Baseline within 12
months of launch in Chrome.
*Adoption expectation*
Feature is used by specific
partner(s) to provide
functionality within 12 months of
launch in Chrome. Feedback from
the Origin Trial indicated that
developers already find the
router source information highly
valuable for tracking and
attribution.
*Adoption plan*
We will notify developers of the
new field names via technical
blog posts and documentation
updates. The temporary
coexistence of old and new fields
ensures a smooth transition for
current users.
*Non-OSS dependencies*
Does the feature depend on any
code or APIs outside the Chromium
open source repository and its
open-source dependencies to function?
No.
*Estimated milestones*
Shipping on desktop 149
Shipping on Android 149
Shipping on WebView 149
*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. The corresponding spec
changes are already added. These
fields are being added
specifically to match the
finalized specification.
Reference:
https://github.com/w3c/resource-timing/pull/415
<https://github.com/w3c/resource-timing/pull/415>
*Link to entry on the Chrome
Platform Status*
https://chromestatus.com/feature/5172259800088576?gate=5871730453250048
<https://chromestatus.com/feature/5172259800088576?gate=5871730453250048>
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]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFXMW90_sBa4FtsM3%2B%3D4LXx0EL9W%2BxdRW%2BzNgAp5cNLwv7mR2g%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFXMW90_sBa4FtsM3%2B%3D4LXx0EL9W%2BxdRW%2BzNgAp5cNLwv7mR2g%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]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL%2BKwEAV6ObwQRLn5ZcoH17choN_ka-6EWGw_L178zhCw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL%2BKwEAV6ObwQRLn5ZcoH17choN_ka-6EWGw_L178zhCw%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]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKDTNmGeGWFi2r1T5i50HU7TqmDqU28L4JzWdLF%2BZpXPg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKDTNmGeGWFi2r1T5i50HU7TqmDqU28L4JzWdLF%2BZpXPg%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0830c66-d308-45b1-9550-b029f0c4efe3n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0830c66-d308-45b1-9550-b029f0c4efe3n%40chromium.org?utm_medium=email&utm_source=footer>.
