A page writes to localStorage, but its own window.addEventListener('storage', ...) handler never runs — while another tab's handler does. Why, and which documents actually receive the storage event?

## What the event is for `localStorage` is shared by every tab on an origin, but each tab has its own JavaScript heap and its own in-memory copy of whatever it read at startup. The `storage` event exists to close that gap: it tells the *other* documents that the shared store changed, so they can reconcile. The asymmetry in the question is the whole design. The specification dispatches the event at every `Window` whose document uses that storage area and origin, except the document that performed the write. From the platform's point of view the writer already has the new value in hand, so notifying it would be redundant. From a developer's point of view this is a trap, because the natural architecture — "write to storage, let the storage handler update the UI" — works in every tab except the one the user is looking at. The fix is to make the write path do both jobs: ```js function setTheme(theme) { localStorage.setItem('theme', theme); applyTheme(theme); // this tab, right now } window.addEventListener('storage', (event) => { if (event.key === 'theme') applyTheme(event.newValue); // other tabs }); ``` ## What the event object carries `StorageEvent` has five properties beyond the usual event members: - `key` — the key that changed, or `null` when `clear()` emptied the store. - `oldValue` — the previous value, `null` when the key did not exist before. - `newValue` — the new value, `null` when the key was removed or the store cleared. - `url` — the URL of the document that made the change. - `storageArea` — a reference to the `Storage` object involved, which lets one handler distinguish a `localStorage` change from a `sessionStorage` one. Always branch on `event.key` first. A handler that assumes its own key was the one that changed will misfire on every unrelated write, including writes from third-party scripts sharing the origin. And handle `key === null` explicitly: that is a `clear()`, which in an auth context usually means "everything went away", not "nothing happened". ## The same-value no-op The `setItem` algorithm compares the incoming value against what is already stored and returns early when they are equal. No write, no event. This quietly defeats the common trick of using storage as a message bus by writing a constant sentinel value: the first write notifies the other tabs, and every subsequent identical write does nothing at all. If you genuinely want to broadcast an event through storage, the value must change each time — a timestamp or a random nonce in the payload — and you should remove the key afterwards so it does not sit in the quota forever. That said, `BroadcastChannel` is the purpose-built API for tab-to-tab messages and does not abuse the store at all; reach for `storage` events when what you are syncing genuinely *is* persisted state. ## sessionStorage fires too, but narrowly The event is not exclusive to `localStorage`. A `sessionStorage` write also dispatches it, but only to other documents sharing that tab's session store — most commonly a same-origin iframe embedded in the page. It never crosses tabs, because the store itself never crosses tabs. ## Delivery is not a guarantee of promptness The handler runs as a task in the receiving document's event loop, so a heavily loaded or backgrounded tab may process it later than you expect; browsers throttle timers and other work in hidden tabs. A page sitting in the back/forward cache is frozen and will not run the handler while it is there. Handlers should therefore be written to converge on the current state — read the value or trust `newValue` and apply it idempotently — rather than to replay a sequence of deltas that assumes nothing was missed. On a page that has just been restored or made visible again, re-reading the store is more reliable than assuming every event arrived. ## Typical uses that hold up Cross-tab logout is the canonical one: when one tab clears the auth key, the others notice `key === 'auth'` with `newValue === null` and navigate to the login screen instead of firing failing requests. Theme and locale changes are similar. Sharing a "someone already refreshed the token" marker is another, though the coordination there is subtle enough that a dedicated lock mechanism is usually safer. ## What a weak answer sounds like "The event fires in all tabs including this one" — it does not. "I'll rewrite the same flag to poke the other tabs" — an identical value writes nothing. "The listener goes on the storage object" — it is dispatched at `window`. Getting these three right is most of what an interviewer is checking.