A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Cross-window Session Storage


I didn’t realize sessionStorage was limited to a single tab until right now. I’ve used that before as a quick way of persisting a value when reloading a page, but in general, that is of very limited utility.

It’s 2015, and the only mechanism web developers have if they want a ephemeral storage for all open tabs on their domain is document.cookie. If I want to read data that is shared across tabs in a semi-persistent fashion, my only choice is to deserialize a substring found by linear search through a serialized collection - one that’s going to get sent with every HTTP request. That is just unbelievable.

(localStorage doesn’t make sense if I’m dealing with things that only apply to the current window configuration - I don’t want those values persisted. And I’m not even going to touch ServiceWorker for this problem.)

I propose we add a Storage value that works exactly the same way as localStorage, except that it has the same rules regarding persistence (and lack thereof) as session cookies. Possible names (bikeshed warning):

  • processStorage (ironically, in process-per-tab browsers, sessionStorage is closer to process storage and processStorage would be closer to session storage)
  • temporaryStorage (I don’t like it because it makes it sound like it has an arbitrary eviction policy)
  • crossSessionStorage (I guess this probably the most accurate name, but do we need another thing in the Web platform that abbreviates as CSS or XSS?)
  • runtimeStorage