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. >>>>>> - workerMatchedSourceType >>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/5117 >>>>>> - 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/f0830c66-d308-45b1-9550-b029f0c4efe3n%40chromium.org.
