Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop isReload #873

Closed
jakearchibald opened this issue Apr 10, 2016 · 14 comments
Closed

Drop isReload #873

jakearchibald opened this issue Apr 10, 2016 · 14 comments
Labels
Milestone

Comments

@jakearchibald
Copy link
Contributor

I think we should go lower level here.

If we supported #817 (comment) I'd be able to tell that a client of url was instigating a navigation request to the same url.

This may be a reload, or may be opening a new window, so additional information like "target" would be needed.

@jakearchibald
Copy link
Contributor Author

Issue for the target client id #874

@jakearchibald
Copy link
Contributor Author

It's possible that knowing the reload button was pressed (or pull-to-refresh) is interesting enough to keep this feature, as the client Ids won't express that.

@wanderview
Copy link
Member

Is the refresh button observable in the FetchEvent.cache value? Doesn't it set it to something that requires revalidation?

@jakearchibald
Copy link
Contributor Author

Chrome seems to request with cache-control:max-age=0 on refresh

(guess you mean fetchEvent.request?)

@wanderview
Copy link
Member

Sorry, I meant FetchEvent.request.cache. Firefox nightly right now generates "default", but I think thats a bug. If I fix the code to actually look at our load flags it returns "no-cache" when the refresh button is pushed.

Gecko bug to fix that FetchEvent.request.cache value: https://bugzilla.mozilla.org/show_bug.cgi?id=1263469

@annevk
Copy link
Member

annevk commented Apr 11, 2016

Yeah, the cache mode is what is actually affected here. Nice catch.

@jakearchibald
Copy link
Contributor Author

F2F: #875 - we can drop isReload if we can get the right information out of .cache.

@slightlyoff
Copy link
Contributor

Spec is blocked on implementation.

@wanderview
Copy link
Member

@jakearchibald
Copy link
Contributor Author

Pre F2F notes: Probably nothing to discuss here.

@jakearchibald
Copy link
Contributor Author

Resolution:

  • The cache mode of the request should reflect the browser's intent
  • You can use this and the clients API to detect a reload vs navigation to the same resource
  • We need to look at location.reload and see if we need to spec a "revalidate all subresources" flag on the env settings object

@jungkees
Copy link
Collaborator

jungkees commented Feb 9, 2017

I'd like to check if we're ready to drop this API. It seems Chromium bug for this (https://bugs.chromium.org/p/chromium/issues/detail?id=453190) is still in progress but its blocking issue (whatwg/fetch#39) had been closed.

/cc @mattto @tyoshino @wanderview @jakearchibald @annevk

@mfalken
Copy link
Member

mfalken commented Feb 9, 2017

Our bug to drop this is https://bugs.chromium.org/p/chromium/issues/detail?id=652994. We're mostly blocked on implementing Request.cache (https://bugs.chromium.org/p/chromium/issues/detail?id=453190) and gathering usage data for FetchEvent.isReload (https://bugs.chromium.org/p/chromium/issues/detail?id=376039).

I think it's ok for the spec to drop this and Chrome will eventually catch up.

@jungkees
Copy link
Collaborator

jungkees commented Feb 9, 2017

We need to look at location.reload and see if we need to spec a "revalidate all subresources" flag on the env settings object

Let's move this question to #875.

a2sheppy added a commit to a2sheppy/browser-compat-data that referenced this issue Feb 19, 2020
Elchi3 pushed a commit to mdn/browser-compat-data that referenced this issue Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants