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/3fdbe729-3ba3-4f64-92fd-2704cbf90c4fn%40chromium.org.
