Should a SW client.id persists across Discards/Reloads of the same page?

[fmeawad]

For a given Client, if the client was discarded in the background due to memory pressure, later restored. Should this client get a new id, or should it keep its original id.

I have tested the current behavior in Chrome, and it seems the Client is assigned a new id. I guess this is expected since the reload would establish a new connection to the SW, and hence get a new id.

But it seems that there might be some use cases where persisting the id across discard/restore can be helpful.

[jakearchibald]

We don't do this for reloads, or navigations to the same URL, so I don't think we should do it in the discarding case.

Unless I'm missing something, it becomes a new client in terms of the HTML & fetch specs, so I don't think we should tell developers a different story here.

Can you post some of the use-cases for knowing a tab is a reload of a discarded tab? I'm sure we can find some answer.

[spanicker]

Our usecases:

1. for SW "update title favicon" API, the SW needs to identify the tab to update -- even if it was discarded. Fadi can provide more details here.

2. tab is discarded in Lifecycle: developer needs to be able to identify the tab and restore its state.
   See: Ensure correct tab can be identified following discard WICG/page-lifecycle#4

3. jsbell mentioned he has a usecase here for Locks API:
   @inexorabletash could you provide some detail / link to bug

If SW client ID is not suitable, we could potentially add a new ID on Window / Document -- but usecase#1 requires it to be exposed to SW also.

[wanderview]

Please define your use case in more detail.

Would making the wasDiscarded state surfaced on reload include the client ID of the discarded window help?

[spanicker]

Yes for usecase#2 explicitly sending an ID with wasDiscarded would work, however if this is explicit then it doesn't really need to SW client ID and could be a random ID that we surface in onfreeze / pagevisibility and echo back in wasDiscarded. Having a unique ID for the tab would obviate this - and potentially also address needs of usecase#1&3.
Let's wait for @fmeawad & @inexorabletash to chime in on that.

[wanderview]

I have concerns about adding another identifier tied to the tab concept. It would need some definition around life cycle, etc. It would be confusing for developers since the difference between it and client ID might be subtle.

Providing the last discarded client ID seems more palatable.

[inexorabletash]

In my use case - https://github.com/inexorabletash/web-locks/blob/master/README.md#management--debugging - I have no dependency either way on the id being re-used across a navigates/restores, as long as at any point in time (1) it is unique to an environment settings object/agent (i.e.. frame or worker) and (2) it matches the SW's client.id (so a SW could roughly correlate).

Providing the last discarded client ID seems more palatable.

Sounds better to me as well.

Note if we expose the ID to the page/worker (is that actively discussed anywhere, BTW?) this could be done in user-space via the history API. (I think this discussion is somewhat predicated on the History API's single value being seen as too restrictive. But if a page has access to the ID, it could push just that into the history, and then use it as part of a key into another storage mechanism before/after restore.)

[wanderview]

Note if we expose the ID to the page/worker (is that actively discussed anywhere, BTW?)

I don't think there is an issue for this. Probably discussed in the odd comment or two in various SW issues, though.

I would be in favor of something like self.clientId or self.navigator.clientId, etc. I don't know enough about the history API to know what makes sense.

[mfalken]

There is issue #955 for exposing the Clients API, but I guess that's different to exposing clientId (even with the Clients API you can't get your own ID easily).

Implementation-wise for Chromium, assigning a new client ID for reload isn't really about a new connection to the SW thread. It's a new Document which translates to a new host in the browser process, which creates a new client ID.

A tab can have multiple clients. Would you want to preserve client id/provide lastDiscardedClientId for all Documents in the reloaded/discarded tab?

[spanicker]

Surfacing "lastClientId" or "lastDiscardedClientId" sounds good to me.
I think Jake was pushing back (earlier in this thread) on preserving the last client-id across reloads as it changes the developer story (and may have compat issue?)
I've updated the HTML issue with this request.

[jungkees]

I think Jake was pushing back (earlier in this thread) on preserving the last client-id across reloads

I think what @jakearchibald said was preserving the same client-id across reloads wouldn't match the existing behavior in terms of the lifecycle of global objects/environments.

But if a page has access to the ID, it could push just that into the history, and then use it as part of a key into another storage mechanism before/after restore.

This sounds interesting. Is the idea something like:

• A client stores its history state keyed by the id.
• The client's tab is discarded and restored.
• The restored client looks up the history state using discardedClientId.

Probably discussed in the odd comment or two in various SW issues, though.

#643 and #955.

[spanicker]

Yes that is exactly the intended usage for lifecycle discarded usecase
We expect the state to be stored in session storage.

[jakearchibald]

Closing in favour of whatwg/html#3378 (comment). Please reopen if I'm way off.