A web app persists the user's unsaved draft in a `beforeunload` handler, with an `unload` handler as a backup, yet mobile users still lose drafts. Why are those two events unreliable, and which lifecycle event is the dependable place to save?

## The mental model that causes the bug Developers picture a page ending the way a desktop program ends: the user closes it, an exit hook runs, cleanup happens. `beforeunload` and `unload` encode that picture. But on the modern web — and overwhelmingly on mobile — a page far more often *stops* than *exits*: the user swipes to another app, locks the phone, or switches tabs, and the page sits in the background until the operating system decides it wants the memory back. When that happens the process disappears. There is no navigation, no teardown sequence, and no opportunity for your handler to run. That is the whole answer to "why did the draft vanish": the code that would have saved it was scheduled for an event that never occurred. ## Taking each event in turn **`unload`.** Fires, when it fires at all, as the document is being discarded during a navigation. It is skipped entirely when a tab is killed while backgrounded, and it is unreliable in practice on mobile even for ordinary navigations. It is also actively harmful: registering an `unload` listener disqualifies the page from the browser's back/forward restore optimisation, so a handler added "just in case" makes back navigation measurably slower for every user. Modern guidance is to not use it at all. **`beforeunload`.** Its real purpose is narrow: give the user a chance to cancel a navigation that would lose work. Calling `event.preventDefault()` inside it asks the browser to show a confirmation dialog — the browser's own generic wording; custom strings have been ignored for years — and browsers only show it if the user has interacted with the page (sticky activation). It has the same fundamental hole as `unload`: no navigation, no event. And it is synchronous-only; an `await`ed save inside it will not complete, because the browser does not wait for your promise. **`visibilitychange` to `"hidden"`.** This fires on every path by which the user stops looking at the page: switching tabs, switching apps, minimising, locking the screen, and also as part of navigating away. It is delivered *before* the page is eligible to be frozen or killed. That makes it the last moment you can count on running code — which is exactly the definition of a durable save point. **`pagehide`.** Fires when the document is being torn down or set aside on a navigation. Useful as a secondary signal for teardown-shaped cleanup, and far better behaved than `unload`, but it does not cover the app-switch case that visibility does. ## The shape of a correct save ```js let dirty = false; function markDirty() { dirty = true; } function persistDraft() { if (!dirty) return; localStorage.setItem('draft', JSON.stringify(collectDraft())); dirty = false; } document.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') persistDraft(); }); window.addEventListener('pagehide', persistDraft); ``` Four properties matter. **Idempotent.** This now runs on every tab switch, dozens of times a session. A dirty flag keeps it cheap and lets the handler be attached twice without harm. **Small and fast.** You are running at a moment the browser is transitioning; a large serialisation blocks it. Keep the payload minimal and prepare it incrementally if it is expensive. **Synchronous-safe.** Anything asynchronous may not finish, because the page can be frozen or killed immediately after the handler returns. A save whose completion depends on a promise resolving after the transition is a save you cannot rely on. **Restored deliberately.** Saving is half the feature. On startup, read the stored draft, and decide the reconciliation rule — offer to restore, merge, or discard on successful submit — so a stale draft does not resurface after the user has already sent it. ## Where `beforeunload` still belongs One place: warning the user before they lose work, registered only while there is unsaved work and removed the instant there is not. A permanently-installed `beforeunload` is a usability bug — it prompts on every exit and offers no information. Use it for the prompt, and never as your persistence mechanism. ## What interviewers listen for The candidate who names `beforeunload` and stops is at the bottom of the range. The candidate who explains that mobile pages are killed while backgrounded, that no unload-family event covers that path, and that the hidden transition is therefore the real save point, is demonstrating exactly the production experience the question is probing. Adding that `unload` handlers cost back/forward restore eligibility, and that the save must be small, idempotent and synchronous-safe, is what separates a good answer from a complete one.