Open bzbarsky opened 5 years ago
cc @yutakahirano
@mattto
@bzbarsky We are working through the related issue from Navigation Timing here at TPAC and we are wondering about how this issue affects "serviceworker bits". Could you be a little more explicit? Thank you!
@toddreifsteck thinks that you are potentially referring to https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/isReload ? But that appears to be removed from the spec.
Can you help us out? Thank you!
FetchEvent.isReload was replaced by Request.isReloadNavigation: https://fetch.spec.whatwg.org/#dom-request-isreloadnavigation
For this issue it sounds like Request.isHistoryNavigation (https://fetch.spec.whatwg.org/#dom-request-ishistorynavigation) is more relevant.
I'm here at TPAC too. I would guess that it should count as a back navigation. This would have been a good issue for the Service Worker WG yesterday. cc @asutherland @jakearchibald @wanderview @youennf
The main use case of isReloadNavigation and isHistoryNavigation was so the service worker can choose to more heavily use cached responses on a back navigation (user is just going back) or more heavily go to network for a reload (user is trying to get a fresh version of the page).
For this issue it sounds like Request.isHistoryNavigation (https://fetch.spec.whatwg.org/#dom-request-ishistorynavigation) is more relevant.
Yes, exactly. What value do service workers see for isHistoryNavigation
for the post-redirect request if the pre-redirect request was caused by a history operation?
If I do
history.back()
, and when the browser fetches that URL (with the history-navigation flag set on the request), if the response is an HTTP 3xx, should the resulting post-redirect request also have the history-navigation flag said? Right now it does not, right?This is relevant for both serviceworker bits and the behavior of https://github.com/w3c/navigation-timing/issues/115