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/CAFXMW92uKLFODwHGb%2BSiCxCiyC5BCMpJaicH2e6%3DvuZyr9j5Og%40mail.gmail.com.
