Ok, LGTM1 On Mon, Nov 2, 2026 at 1:52 AM Yoav Weiss (@Shopify) <[email protected]> wrote:
> 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/CAFUtAY8%3DjkBJ6q%3DhfivZOzfca%2B-GoArB1yPWGqw761qF%2B2iivA%40mail.gmail.com.
