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/27224c64-6483-4a24-9ee2-a43f81552a7bn%40chromium.org.
