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/CAARdPYc3unvrZM4Y31Q%2B0iHN3xn4aHu%2B1Yo7a5C_%2B5zhsbqi5Q%40mail.gmail.com.
