Ensure correct tab can be identified following discard

[spanicker]

Let's say there are two tabs (tab1 and tab2) from an origin with identical URL, say foo.com.
They are both in the background and are both discarded.
Now the user revisits tab2 -- Document will surface "wasDiscarded" to allow restoring state that might have been saved in prior onfreeze or pagevisibility event.
However the app should be able to know that it needs to restore state for tab2 as opposed to tab1.

Could the app use sessionStorage to reliably record session instance?
@inexorabletash
@toddreifsteck

[inexorabletash]

As long as the two tabs were not "scriptable" from each other (i.e. one did not launch the other, or they weren't both launched from the same tab) then sessionStorage should be unique between them. As long as we don't discard sessionStorage when a page is discarded, that would work. As long as we distinguish (in both spec and implementation) page discard vs. session ending, it should be okay.

In the case where the tabs are part of the same session, they'd need to somehow mint unique IDs and key storage off of that, and stash the ID via the page history API or something.

[inexorabletash]

Potentially relevant: over on w3c/ServiceWorker#1254 @jakearchibald wrote:

If we want to expose the clients API to all pages...

I haven't been part of that discussion, but part of the clients API is a unique identifier per page. (I'm leaning on that over in https://github.com/inexorabletash/web-locks too). Spec-wise, this is defined as the environment's id which is not (?) yet (?) exposed to script directly. If it was, a page could use that as part of a key for page-specific state storage.

[spanicker]

@fmeawad - see link to exposing Client API

[spanicker]

I like the idea of exposing Client ID.
I'll check whether the app could use History API.
Tabs may very well be part of the same session and we need to support restoring after discard, so sounds like session storage is not the best fit here.

[spanicker]

Asking apps to use History API to workaround this seems bit unpalatable.
Exposing clientId and lastClientId on Document / Window would address our needs here.