Spec persistence of session storage

[jakearchibald]

https://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage

When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved.

From page-lifecycle docs, it seems that session storage is intended to be persisted between the discarded & active state.

This behaviour doesn't look clearly spec'd right now, but it feels really important, and something we'd want to be interoperable.

[domenic]

Does the discarded state actually destroy the browsing context?

Edit: yes, it does, hmm. May be more stuff like this that needs auditing.

[spanicker]

@inexorabletash - Josh - could you verify that our assumption about session storage makes sense, we can then update the spec.

FWIW we did test locally in chrome and session storage worked fine across discards, the question is whether that can be relied upon.
\cc @philipwalton

[inexorabletash]

Ping @mkruisselbrink and @dmurph

[jakearchibald]

Session storage also survives crashes. I can't figure out if that's spec'd or not.

[mkruisselbrink]

I don't think crashing is spec'ed at all (and I think in chrome-on-android session storage doesn't actually survive crashes, as we discovered somewhat recently). But yeah, I would definitely expect session storage to survive as long as some kind of notion of having the same tab is still around (i.e. in chrome that means undoing closing a tab will also retain session storage). Not sure how the page lifecycle stuff is spec-ed (I can't make much sense of the existing spec, https://wicg.github.io/page-lifecycle/spec.html#page-lifecycle talks about additions to the page lifecycle spec, but isn't that the page lifecycle spec itself? It certainly doesn't reference any other page lifecycle specs...)

[spanicker]

Thanks for confirming that session storage should survive and predictably keep functioning if a background tab is discarded and later revisited by the user. Yes, the notion of the "same tab" applies here.
However, there is no concept of "tab" in the HTML spec IIRC, it starts with the browsing context within the tab, and the latter will not survive a discard (or crash etc).
So I am not sure how it could be spec'd, @domenic may have ideas.

[domenic]

I think what we'd want to do here is emulate the copying mechanism used for popups.

We would then state that https://wicg.github.io/page-lifecycle/spec.html#discarded saves a copy, and in a place similar to https://html.spec.whatwg.org/multipage/browsers.html#copy-session-storage talk about restoring it if we were previously discarded. Similar to how we do the discarded boolean.

[jesup]

I'm fairly certain that the specs say nothing about persistence of session storage across crashes or restarts; they certainly don't mandate such persistence. Last time I checked (which was a long time ago), Firefox persisted such data, and Chrome did not. (I don't know about IE/Edge/Safari, but I'm guessing they don't.)

This is part of why Firefox's session recovery data was so large - Google (for example) often stores 100's of K of data in session storage (or did at least until recently - around a year ago we landed bug 1362058, which limited DOMSessionStorage size saved to disk to 2K per origin (or might be per-origin-per-tab)).

For this api, I think session storage should persist for the user's concept of the session (tab); the fact that it was frozen/unloaded and thawed/reloaded should be largely transparent to the user.

[jakearchibald]

My point is, if page-lifecycle is recommending session storage for keeping data between discard/reload, it needs to be specced well enough to be interoperable.