Ok, LGTM1
On Mon, Nov 2, 2026 at 1:52 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
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
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>.
