Allow 'session' bucket

[jakearchibald]

Session storage is excellent for storing data against the tab. This is useful for storing app state that survives a 'discard' on mobile, or even a crash.

However, session storage only supports strings, and its synchronous API has the same issues as localstorage.

It'd be nice if a bucket, or other unit of storage, could be associated with the session.

[annevk]

cc @asutherland

[asutherland]

It sounds like the storage would be keyed per-tab (top-level browsing context).

Would the "session" bucket also share the existing SessionStorage semantics where the existing storage is forked whenever new tabs (top-level browsing context) are opened from the current tab? If so, how would that interact with APIs like IndexedDB?

Relatedly, would the bucket would be something that could be postMessaged and used by other globals?

Would there be storage limits? Firefox doesn't (or at least didn't for a VERY long time) bother writing large SessionStorage values to disk. So state would be lost if the session was restarted.

[jakearchibald]

Would the "session" bucket also share the existing SessionStorage semantics where the existing storage is forked whenever new tabs (top-level browsing context) are opened from the current tab?

It'd be nice if we could 'explain' sessionstorage as being localstorage but in a "session" bucket.

However, there's an opportunity to change behaviour if there's good reason.

That was a long way of saying 🤷‍♂️

If so, how would that interact with APIs like IndexedDB?

Could it behave the same? The storage is copied on forking. I guess this would create quota issues unless the browser avoids copying unless the values are modified.

Relatedly, would the bucket would be something that could be postMessaged and used by other globals?

I don't think so. Was the plan to allow buckets to be otherwise postMessaged? Values from the bucket could be postMessaged though.

Would there be storage limits?

I'm not sure. If it's gone when the user closes the tab, it feels different to regular storage quota. Although we still wouldn't want sites to be able to fill up the user's disk. Are there other APIs that temporarily write to disk? Blobs perhaps?

Firefox doesn't (or at least didn't for a VERY long time) bother writing large SessionStorage values to disk. So state would be lost if the session was restarted.

I think it should survive a tab crash & discard (as in, when the 'tab' is still there, but it's been evicted from memory). The page lifecycle API kinda depends on this, and I'm a little grumpy that the session storage spec wasn't updated to make this clear. WICG/page-lifecycle#26

It guess it wouldn't matter if session storage was left as it is and treated as legacy, whereas the "session" bucket had a stricter definition.

[jakearchibald]

Related: whatwg/html#3378 (comment). A proposal for a "browsing session" concept

[annevk]

@jakearchibald yeah, that's what I plan on using. See #2 and #86 for a sketch. Couple questions came up there:

1. Should existing APIs be able to join sessionStorage's bucket in theory if you could get a handle to that bucket?
2. Should a session bucket support multiple APIs or should each API get its own bucket?

Some of this relates to whether or not we want to support auxiliary cloning generally or only for specific buckets.

cc @mkruisselbrink

[jakearchibald]

Hmm, yeah, the copying behaviour is kinda weird, and maybe not something you'd want for other storage systems like 'session' IDB. On the other hand it's weird to have it on one kind of session storage but not the other.

[mkruisselbrink]

I don't really want to have to implement the copying behavior for other storage systems, if I can avoid it... But also agree that it does seem weird to have two different kinds of "session" storage.

What use cases are we envisioning for session storage for other storage systems? Do those use cases actually require the cloning behavior? I think my initial inclination would be that we don't want this cloning for anything other than the "legacy" session storage API.

Not sure what the difference would be between each API getting its own session bucket, vs multiple APIs sharing the same session bucket?

[annevk]

In general I'm personally kinda wary of auxiliary browsing contexts due to all their problems, but even with COOP they remain supported (if same-origin). And if we want people to not use synchronous storage APIs, getting them off sessionStorage might be tricky if the alternatives do not support the same kind of behavior.

Effects of sharing a bucket depends a bit on other features buckets might gain, but one piece here is that a bucket is the smallest unit a user agent is allowed to clear to free up storage. So if we have multiple session buckets in theory you could end up with some of them cleared but not all due to storage pressure.

[asutherland]

I also don't like the idea of expanding the copying semantics beyond sessionStorage. There are both implementation and conceptual complexities that would be hard to be address and don't seem justified.

What if the browsing context group owns the browsing session storage map? That way the auxiliary browsing contexts have live access to the same storage as their browsing context opener. This could be exposed on globals as navigator.storage.sessionBucket and perhaps even to ServiceWorkers as Client.sessionBucket.

If the auxiliary browsing context doesn't want this helpful feature, then it could either use the proposed multiple storage bucket mechanism somehow, or (worse idea) there could be a separate storage map for each top-level browsing context individually and both are accessible.

[annevk]

The browsing context group is not a good owner I think. It has no relation to a browsing session and can go away upon navigation due to COOP. I suppose we could go with a narrower variant of session that simply matches its lifetime, but with it still being a bit unclear when we want to replace the browsing context group in non-COOP scenarios I'd rather not.

I think what I'll do for now is that in principle this kind of thing could be supported architecturally for all session buckets, but that we only fork the session bucket that backs sessionStorage.

[jakearchibald]

fwiw, my use-case would be mostly taken care of if a page could access its session ID, and parent session ID, along with a way to get all the session IDs that were still potentially accessible (either active, or resurrectable somehow). Then developers could store session data in normal indexeddb, and manually delete old sessions.

[asutherland]

Then developers could store session data in normal indexeddb, and manually delete old sessions.

I think it would be preferable to bias things so that extra manual bookkeeping that requires extra manual cleanup to eliminate the storage use isn't necessary. This would also aid in more granular eviction since the browser eviction logic would see many small buckets that explicitly are not durable instead of a single large opaque durable-ish bucket.

along with a way to get all the session IDs that were still potentially accessible (either active, or resurrectable somehow)

This seems like it would massively increase the abilities of sites to track user access patterns beyond current capabilities.

[annevk]

From a tracking perspective it might be better if session storage wasn't automatically cloned. Do sites rely on this to begin with?

If the popup is cooperating with its opener it could always manually get the relevant data, so I'm inclined to only clone the "default" session storage bucket and leave it at that, but the architecture is pretty flexible in case we end up wanting something else when we get around to a bucket API.

[pwnall]

sessionStorage cloning has been a PITA in Chrome, from an implementation and maintenance perspective. Please let's never do that again? 😄