Request.isReloadNavigation

[hjanuschka]

Specification title

Request.isReloadNavigation

Specification or proposal URL (if available)

https://fetch.spec.whatwg.org/#dom-request-isreloadnavigation

Explainer URL (if available)

No response

Proposal author(s)

No response

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Request/isReloadNavigation

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

No response

WebKit standards-position

WebKit/standards-positions#620

Other information

This is a read-only boolean attribute on the Fetch API's Request interface that indicates whether the request was initiated by a reload navigation (e.g., the browser refresh button, location.reload(), or history.go(0)). It is primarily useful within a Service Worker's FetchEvent handler for implementing cache strategies that differentiate between normal navigations and reloads.

The attribute is already defined in the Fetch spec and has existing WPT coverage. Chromium implementation: https://chromium-review.googlesource.com/c/chromium/src/+/7137783 (expected to land behind a flag soon).

[hjanuschka]

WebKit standards-position request: WebKit/standards-positions#620

[valenting]

CC @farre @smaug----

[smaug----]

So the feature was added to the spec ~8 years ago and no one seemed to really ask for it for years in the implementations. Has something happened why it is needed now?

(And I'm not saying it shouldn't be implemented. Just curious why. Having a feature for the sake of having a feature isn't too useful.)

[smaug----]

@hjanuschka any particular reason to implement it now? It was unimplemented for so many years that it should have been removed from the spec. What is the reason to implement it now?

[hjanuschka]

Good question! A few things came together:

I've been working through Chromium's Fetch WPT failures (crbug.com/40487194) and isReloadNavigation was one of the remaining gaps.

i did not check the standards-position before starting work, chromium CL is ready and reviewed ( https://chromium-review.googlesource.com/c/chromium/src/+/7137783)

[smaug----]

That still doesn't explain why to implement this. Failing test for a feature no one has asked for hints still that the feature should be removed. There should be some signs that devs really want this.

[hjanuschka]

The use case: a cache-first service worker needs to know when the user hit reload so it can bypass cache and fetch fresh. There's no reliable way to do that today. Devs asked for this.

Nobody demanded it for 8 years because no browser shipped it?

That said, if there's no consensus here I'm happy to close the Chromium CL. No hard feelings either way.

[smaug----]

I don't have strong opinions, but if someone asked for it 2017 and then nothing got implemented, that isn't a very strong signal.
If there was and is a clear need for the feature, there must be now some other way to deal with the situation.
And if that other way is very cumbersome, yes, then we should add a better API.

@jakearchibald might remember this stuff.

[jakearchibald]

The use-case @hjanuschka mentioned is correct. Browsers have a reload button, unlike native apps. But, if a native app has a reload button, you wouldn't expect it to return stale data, so this feature was to allow developers to plug this gap.

Making something work well offline is hard I guess (lots of the "we'll just handle it for you" libraries produced poor results imo), so it isn't something lots of people take on, which might explain the lack of people asking for this feature. I'm just guessing though.

[zcorpan]

Is there a way to address the use case without adding this API? E.g. clear the SW cache on reload?

Or maybe the page wants control over which things to invalidate on reload (only reload content that is likely to have changed), in which case I think this makes sense.