Add a way to detect reloading only client

[AshleyScirra]

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?

[jakearchibald]

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.

I think this should just be clientId #817 (comment)

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.

[jakearchibald]

This is taken care of by other issues.