Leaving with unsaved changes must intercept, not silently discard

What it is

An editor, a settings page, a long unsent comment already holds unsubmitted changes. The next navigation, tab close, or refresh will wipe them from memory. An intercept prompt asks, before that leave actually happens, whether to discard or keep. Silent discard turns “glance at something else” into irreversible deletion. The browser’s beforeunload is the underlying hook; the product’s own route guard must cover in-SPA jumps, which often never fire the native dialog.

If a same-session draft has already been written to a recoverable layer, leave need not intercept—that is keep, not discard. Intercept is for changes that will be gone if this leave proceeds.

Why it happens

Unsubmitted values live as long as the document or component instance. Close, refresh, and route unmount end the instance. Intent is often a temporary leave: check a number in mail, look up a word. Without intercept, temporary leave and abandon are the same action. Discovery of the loss lags: the person is already on the next page, return is empty, the loss happened on the previous click and undo cannot reach it.

beforeunload covers tab close, window close, typing in the address bar, and refresh, and modern browsers lock the copy to a generic sentence; the product’s “your application will be lost” often never shows. In-SPA pushState does not go through it. So intercept is two layers: the native hook to stop a real document teardown; a route guard to stop the next in-site hop. The guard must offer “keep and go” (save, then navigate) and “discard and go”; “Cancel” alone traps people on the page.

Studying it

On a page with unsubmitted changes, arrange a leave (in-site link, refresh, tab close). Compare no prompt, a generic beforeunload, and a product dialog with actions.

• Dependent variables: whether the changes are still there, whether loss is described as an accident, the split between keep and discard.
• Independent variables: leave channel, whether loss would actually happen (session draft or not), whether the dialog offers save.
• Methodological note: in the lab people know there is unsaved work and become careful. Harder: let them click a harmless-looking in-site link while they believe a draft will be kept automatically. Testing only beforeunload misses in-SPA jumps—the most common leave in the product. Do not count leave after “Publish”; there are no unsubmitted changes then.

Where it stops holding

Do not intercept when there are no unsubmitted changes. Read-only browsing, or continuing after a save, makes intercept a false alarm. Mobile Safari’s beforeunload support is incomplete; tab close may still be silent, so earlier automatic writes are needed rather than this one hook. After a user repeatedly dismisses the browser’s leave dialog, the browser shows it less; the product cannot assume every tab close will ask.

Applying it

• Track dirty state. When changes have not been written to a recoverable layer, arm both native beforeunload and the SPA route guard.
• The guard offers keep (save or write a draft, then go) and discard; cancel stays on this page.
• Tear the hooks down as soon as dirty state clears, so the next harmless hop does not fire.
• Verify: change an unsaved field, then tap another in-site page, refresh, and close the tab. All three must allow keep or an equivalent protection. After the draft is session-recoverable, an in-site next page should not prompt—there is nothing to lose. An implementation that intercepts tab close but not routing will silent-discard on an in-site click, and fails.

Related

• Within the group: G4.08.1 External links must look different from in-site links so the jump can be predicted · G4.08.3 Jumping to another domain is a trust transfer; high-risk cases need a second confirm · G4.08.4 Leave prompts only where data would actually be lost; overuse numbs people · G4.08.5 Outbound jumps may send referrer data; sensitive cases must disclose or block
• Adjacent: G4.07 State persistence and position restoration · H1.08 Draft autosave · H3.05 Overuse of confirm dialogs
• Search terms: beforeunload · unsaved changes · navigation guard