Thanks, Patrick. In the interest of our bias to exposing what's available through other means in a reasonable way, and to solve the problems of the developers we've talked to from Edge first-party discussions, LGTM1.
Best, Alex On Wednesday, March 25, 2026 at 9:10:40 AM UTC-7 Patrick Brosset wrote: > Sorry about the late reply you all. > I did try to probe for developer interest but couldn't get much: > > See these posts and their replies: > > - > https://www.linkedin.com/posts/patrickbrosset_if-you-use-a-service-workers-fetch-event-activity-7437930521302740992-uLE2?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABm63wB9NIFWK7Z8l7ky8iGh6Y2nJRE5dY > - https://bsky.app/profile/patrickbrosset.com/post/3mgv2eqiwr22f > - https://mas.to/@patrickbrosset/116217663912018070 > > Hope those are still a little bit helpful. > > Patrick > On Tuesday, 3 March 2026 at 20:42:26 UTC+1 Alex Russell wrote: > >> A random thought: I don't know that we're going to get great data from >> other vendors, rather than web developers directly. >> >> Thomas, Patrick: any chance we can use the various browser devrel bat >> signals to ask developers if they'd like/hate this addition? >> >> Best, >> >> Alex >> >> On Thursday, February 26, 2026 at 10:16:19 PM UTC-8 Philip Jägenstedt >> wrote: >> > For a small addition to an existing API, developer signals are often not >>> as easy to come by, in particular it's not going to come up in surveys and >>> https://github.com/web-platform-dx/developer-signals doesn't track at >>> this granularity. >>> >>> You can look for the discussion that occurred when the spec change was >>> made. These issues and PRs seem relevant: >>> https://github.com/w3c/ServiceWorker/issues/1167 >>> https://github.com/whatwg/fetch/pull/685 >>> https://github.com/whatwg/fetch/issues/1280 >>> >>> "Developers want to simply know if a navigation was due to reload or >>> back/forward" makes sense, but do you know what developers have been doing >>> to work around this all these years? >>> >>> I think the main risk is that this has been sitting idle in the spec for >>> so long and nobody has given it any thought recently. Letting the standards >>> positions sit for a week or two to get some reactions would be good. >>> >>> On Fri, Feb 27, 2026 at 6:02 AM Helmut Januschka <[email protected]> >>> wrote: >>> >>>> asking for standard positions: >>>> https://github.com/mozilla/standards-positions/issues/1360 >>>> https://github.com/WebKit/standards-positions/issues/620 >>>> >>>> not sure how to get "developer signal" >>>> >>>> >>>> [email protected] schrieb am Dienstag, 17. Februar 2026 um 20:08:25 >>>> UTC+1: >>>> >>>>> On 2/14/26 5:48 p.m., Helmut Januschka wrote: >>>>> >>>>> hello olli, >>>>> sorry, messed up the entry, fixed it >>>>> >>>>> Looking at the chromestatus entry - it now shows "No Signal" for both. >>>>> Can we request Signals? >>>>> >>>>> >>>>> Am Sa., 14. Feb. 2026 um 22:56 Uhr schrieb Smaug <[email protected]>: >>>>> >>>>>> >>>>>> *> Gecko*: Shipped/Shipping >>>>>> >>>>>> *> WebKit*: Shipped/Shipping >>>>>> >>>>>> Is that correct given the following. >>>>>> Gecko: >>>>>> >>>>>> https://searchfox.org/firefox-main/rev/c3797cdebac1316dd7168e995e3468c5a597e8d1/dom/webidl/Request.webidl#17 >>>>>> >>>>>> Webkit: >>>>>> >>>>>> https://searchfox.org/wubkat/rev/db628492e5f463663cc3c393dfdd3a641f23d8f8/Source/WebCore/Modules/fetch/FetchRequest.idl#36-37,54 >>>>>> >>>>>> and >>>>>> https://wpt.fyi/results/service-workers/service-worker/fetch-event.https.html?label=experimental&label=master&aligned >>>>>> >>>>>> -Olli >>>>>> On Saturday, February 14, 2026 at 11:33:29 PM UTC+2 >>>>>> [email protected] wrote: >>>>>> >>>>>>> *Contact emails* >>>>>>> [email protected] >>>>>>> >>>>>>> *Specification* >>>>>>> https://fetch.spec.whatwg.org/#dom-request-isreloadnavigation >>>>>>> >>>>>>> *Summary* >>>>>>> Adds the read-only boolean attribute isReloadNavigation to the Fetch >>>>>>> API's Request interface. This attribute indicates whether the current >>>>>>> navigation request was initiated as a user-triggered reload (e.g., >>>>>>> using >>>>>>> the refresh button, location.reload(), or history.go(0)). This signal >>>>>>> is >>>>>>> primarily exposed on the Request object within a Service Worker's >>>>>>> FetchEvent. >>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/7137783 >>>>>>> >>>>>>> *Blink component* >>>>>>> Blink>Network >>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> >>>>>>> >>>>>>> *Web Feature ID* >>>>>>> network-information >>>>>>> <https://webstatus.dev/features/network-information> >>>>>>> >>>>>>> *Motivation* >>>>>>> Web developers, particularly those implementing Service Worker >>>>>>> caching logic, currently lack a reliable, standardized way to >>>>>>> distinguish >>>>>>> between a regular navigation (forward/back) and a user-initiated >>>>>>> reload. >>>>>>> This capability is crucial for implementing sophisticated and efficient >>>>>>> caching strategies, such as bypassing the cache or enforcing a >>>>>>> Network-First strategy specifically during a reload to ensure the user >>>>>>> gets >>>>>>> the freshest content. This attribute standardizes the mechanism >>>>>>> required by >>>>>>> the Fetch spec. >>>>>>> >>>>>>> *Initial public proposal* >>>>>>> *No information provided* >>>>>>> >>>>>>> *TAG review* >>>>>>> *No information provided* >>>>>>> >>>>>>> *TAG review status* >>>>>>> Not applicable >>>>>>> >>>>>>> *Risks* >>>>>>> >>>>>>> >>>>>>> *Interoperability and Compatibility* >>>>>>> Low Risk: The feature is additive. It introduces a new, read-only >>>>>>> property to the existing Request interface, meaning it does not change >>>>>>> the >>>>>>> behavior or signature of any existing methods or properties. Existing >>>>>>> web >>>>>>> content that does not reference isReloadNavigation will continue to >>>>>>> function exactly as before. >>>>>>> >>>>>>> *Gecko*: Shipped/Shipping >>>>>>> >>>>>>> *WebKit*: Shipped/Shipping >>>>>>> >>>>>>> *Web developers*: Strongly positive >>>>>>> >>>>>>> *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? >>>>>>> *No information provided* >>>>>>> >>>>>>> >>>>>>> *Debuggability* >>>>>>> *No information provided* >>>>>>> >>>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>> No >>>>>>> >>>>>> Where will it be supported? >>>>> >>>>> >>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>> No >>>>>>> >>>>>> There seems to be some test coverage. What's missing? >>>>> >>>>> >>>>>>> >>>>>>> *DevTrial instructions* >>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/7137783 >>>>>>> >>>>>>> *Flag name on about://flags* >>>>>>> *No information provided* >>>>>>> >>>>>>> *Finch feature name* >>>>>>> RequestIsReloadNavigation >>>>>>> >>>>>>> *Rollout plan* >>>>>>> Will ship enabled for all users >>>>>>> >>>>>>> *Requires code in //chrome?* >>>>>>> False >>>>>>> >>>>>>> *Tracking bug* >>>>>>> https://issues.chromium.org/issues/40487194 >>>>>>> >>>>>>> *Estimated milestones* >>>>>>> Shipping on desktop 146 >>>>>>> Shipping on Android 146 >>>>>>> Shipping on WebView 146 >>>>>>> Shipping on iOS 146 >>>>>>> >>>>>>> *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). >>>>>>> *No information provided* >>>>>>> >>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>> >>>>>>> https://chromestatus.com/feature/5154214529597440?gate=6489806081228800 >>>>>>> >>>>>>> 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/CAFmjHKSe3X8b_JA_n6r%3DddFXU7dkEmxLbKGqDshc3K-KaYtLRw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFmjHKSe3X8b_JA_n6r%3DddFXU7dkEmxLbKGqDshc3K-KaYtLRw%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/4a305b81-ce9b-4748-b813-a12dd57c11bdn%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4a305b81-ce9b-4748-b813-a12dd57c11bdn%40chromium.org?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/873a1631-a884-4db4-9989-9d40b300e718n%40chromium.org.
