Exit warning

Problem Context

• The task includes typed answers, selected records, uploads, payment setup, edited content, in-progress review, temporary calculations, or session-bound state.
• The product cannot guarantee recovery through autosave, draft state, server session, local storage, or transaction replay.
• Users may leave through Back, close tab, reload, external link, sidebar navigation, breadcrumb, sign out, idle timeout, or route change.
• Browser-owned unload dialogs have limited custom copy and unreliable mobile behavior, so the product still needs local dirty-state messaging and recovery.

Selection Rules

• Choose exit warning when departure has already been attempted and leaving would lose work or context that is not safely recoverable.
• Do not show exit warnings for clean state, read-only browsing, already-saved drafts, completed submissions, or changes that autosave can reliably restore.
• Use autosave form to reduce the need for warnings by saving progress automatically and warning only while saves are pending or failed.
• Use draft state when the work survives navigation as a durable object with Resume, Discard, Publish, or Compare choices.
• Use confirmation dialog when the trigger is an explicit action such as Cancel application, Delete file, or Discard draft rather than a navigation attempt.
• For in-app navigation, show a custom warning that names the affected section, last saved state, and intended destination.
• For tab close, reload, or browser Back outside app control, attach beforeunload only while dirty state exists and remove it after save or discard.
• Offer Stay editing as the safest default when data loss is likely; offer Discard and leave only with clear loss scope.
• Offer Save and leave only when save can complete safely before navigation or when users understand that leaving waits for save completion.
• If mobile or browser behavior cannot guarantee a warning, preserve local draft state or show earlier in-page risk messaging instead of relying solely on beforeunload.

Required States

• Clean state with no exit warning attached.
• Dirty unsaved state with local unsaved-work status.
• Pending autosave or upload state.
• Failed save state with retry before leaving.
• In-app route change attempted state with destination named.
• Browser close, reload, or external navigation protected state.
• Save and leave in progress state.
• Discard and leave confirmation state.
• Stay editing state that restores focus and preserves values.
• Saved or submitted state that clears the warning.

Interaction Contract

• The warning appears only after a departure attempt or immediately before a known session boundary that could cause loss.
• The warning identifies the scope of loss, such as Contact details, uploaded evidence, payment setup, or unsaved section answers.
• Stay editing keeps the user on the current surface with values intact and returns focus to the triggering or first dirty control.
• Discard and leave clears only the stated unsaved work and then completes the intended navigation.
• Save and leave either completes the save before navigation or explains that saving failed and keeps the user on the page.
• The browser beforeunload listener is attached only while dirty state exists and removed after save, submit, discard, or reset.
• A warning never traps users after they explicitly discard or after the work is safely recoverable.

Implementation Checklist

• Define dirty state from actual data changes, pending uploads, failed saves, in-flight payment setup, or unrecoverable session context rather than from page visit alone.
• Track the intended destination for in-app navigation so the warning can continue there after save or discard.
• Keep browser beforeunload protection conditional and remove it as soon as risk clears.
• Use route guards for internal links, Back controls, breadcrumbs, side navigation, sign out, and cancel routes that could lose current work.
• Model Save and leave, Discard and leave, Stay editing, Retry save, and Continue to destination as separate actions.
• Handle pending or failed autosave differently from simple dirty state; do not allow a stale Saved label to suppress the warning.
• Restore focus after Stay editing and announce the preserved state for assistive technology users.
• Test browser reload, tab close, mobile app switch, internal route change, external link, sign out, session expiry, failed save, successful save, discard, Back button, keyboard activation, and screen readers.

Common Generated-UI Mistakes

• Warning on every navigation regardless of whether work is dirty.
• Using exit warnings for retention, growth, ads, or survey prompts instead of preventing user-facing loss.
• Leaving beforeunload listeners attached after save, harming navigation and browser-cache behavior.
• Showing a vague Are you sure? message without naming the affected work or consequence.
• Providing only Leave and Cancel when Save and leave or Stay editing is technically possible.
• Trapping users after they choose to discard or after work is saved.
• Relying only on browser beforeunload even though mobile browsers may not show it reliably.

Critique Questions

• What exact work or context would be lost if the user leaves now?
• Is the loss unrecoverable, or can autosave or draft state make the warning unnecessary?
• Which exit paths are covered: internal links, Back, reload, close tab, external links, sign out, and session expiry?
• Does the warning say what will be lost and where the user was trying to go?
• Can users save before leaving, discard intentionally, and stay editing without losing focus or values?
• Is the browser leave listener removed immediately after save, submit, or discard?