You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Client lifetimes overlap when reloading a page, so at the "navigate" request after pressing reload, there will appear to be two clients (or just the old one because clientId is null? not clear on this). This makes it hard to know if the page is being reloaded with no other clients open, which is an opportunity to do an update if some new data has been downloaded. I think there should be a way to easily detect this case.
I don't think the existing isReload property tells you much, since it doesn't appear to tell you anything about other clients. Also I am not that familiar with SW so forgive me if this is already possible some way!
For example maybe the "navigate" fetch event could have previousClientId. There would probably need to be a non-null clientId in the navigate event as well for this to be useful. This would mean that:
if this is a "navigate" fetch,
isReload is true,
clients.matchAll() consists only of previousClientId and the new clientId,
I know that my SW will serve a document that replaces the previous client and doesn't start a download or otherwise leave behind the old client
...then it is safe to update if new data is waiting.
Alternatively maybe there could be a separate isOnlyClientReload flag to detect the same?
The text was updated successfully, but these errors were encountered:
Client lifetimes overlap when reloading a page, so at the "navigate" request after pressing reload, there will appear to be two clients (or just the old one because clientId is null? not clear on this)
I think there should only be one client, as Firefox reports #870.
I don't think the existing isReload property tells you much, since it doesn't appear to tell you anything about other clients.
I think we should drop isReload#873 - what do you think?
For example maybe the "navigate" fetch event could have previousClientId.
There would probably need to be a non-null clientId
We're calling this potentialClientId, because it may never exist.
I know that my SW will serve a document that replaces the previous client
You don't if the potentialClientId is going to replace a completely different client to the request's clientId, as would happen with the target attribute of links. We need something like targetClientId I think.
Client lifetimes overlap when reloading a page, so at the "navigate" request after pressing reload, there will appear to be two clients (or just the old one because clientId is null? not clear on this). This makes it hard to know if the page is being reloaded with no other clients open, which is an opportunity to do an update if some new data has been downloaded. I think there should be a way to easily detect this case.
I don't think the existing
isReload
property tells you much, since it doesn't appear to tell you anything about other clients. Also I am not that familiar with SW so forgive me if this is already possible some way!For example maybe the "navigate" fetch event could have
previousClientId
. There would probably need to be a non-nullclientId
in the navigate event as well for this to be useful. This would mean that:isReload
is true,clients.matchAll()
consists only ofpreviousClientId
and the newclientId
,...then it is safe to update if new data is waiting.
Alternatively maybe there could be a separate
isOnlyClientReload
flag to detect the same?The text was updated successfully, but these errors were encountered: