- From: Andrew Sutherland <notifications@github.com>
- Date: Thu, 25 Feb 2021 08:18:51 -0800
- To: whatwg/storage <storage@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/storage/issues/119/786022575@github.com>
I believe that already happens. The current spec mutates the single [map](https://html.spec.whatwg.org/multipage/webstorage.html#concept-storage-map) and calls [broadcast which queues a task](https://html.spec.whatwg.org/multipage/webstorage.html#concept-storage-broadcast). This works in a straightforward fashion under a single-process model assuming all windows run on the same event loop/main thread; the current state of the map always reflects the JS code that has executed and the events are after-the-fact delta notifications. We don't specify what happens under a multi-process model; I think this would be the first time we're addressing it. Practically speaking, this can be very implementation dependent. On Firefox Release, Legacy LocalStorage processes storage broadcasts as they are received via IPC and updates the underlying (local process) map just before dispatching the events so content is perceiving a replay of what happened in the other process like the events had been dispatched synchronously instead of rather than asynchronously via a task. On Firefox Nightly, LocalStorage NextGen approximates the single-process situation wherein a (coherent snapshot of) the single backing map will be seen that is entirely up-to-date when the event is received / processed. -- 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/119#issuecomment-786022575
Received on Thursday, 25 February 2021 16:19:04 UTC