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
o WorkerFinalSourceType
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],
[email protected]
*Specification*
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
*Link to entry on the Chrome Platform Status*
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].
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].
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].
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/b1b4991a-e757-4874-96a5-652d0df62045%40chromium.org.
