Re: [whatwg/storage] Allow 'session' bucket (#71)

> 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. https://github.com/WICG/page-lifecycle/issues/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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/71#issuecomment-494876208