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/bc4fe273-f831-45c8-aa96-dbd213a74936n%40chromium.org.
