LGTM3 On Wed, Apr 29, 2026 at 5:16 PM Rick Byers <[email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY80sj9Ky256c-Cz2V3v7rA9OmOECq231mmgyvjYg%2Bvwpw%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/CAOmohSJFg4jNhtAhTSJHvAO0oDtbXzX05k-Zp7PqZh2Z3VEiwQ%40mail.gmail.com.
