Seems pretty minor and reasonable architecturally, it doesn't seem worth the effort to me to relitigate whether this should be in the HTML spec or not. LGTM2
On Tue, Apr 28, 2026 at 2:34 PM Alex Russell <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/873a1631-a884-4db4-9989-9d40b300e718n%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/CAFUtAY80sj9Ky256c-Cz2V3v7rA9OmOECq231mmgyvjYg%2Bvwpw%40mail.gmail.com.
