Unexpected exit should keep a draft, not drop the work

What it is

Edits in edit mode that are not yet the live official draft can be killed with the process: browser crash, dropped network, the OS discarding the tab. That is unexpected exit. A recoverable draft should remain, and the next open of the same object should offer to resume after confirm, not treat the work as never happening. This is involuntary interruption. Whether a back tap asks first is intentional leave. How often a form autosaves and whether that state is visible is another layer of drafts. The question here is only: after the system interrupts edit mode, is the work gone.

Why it happens

Unexpected exit offers no decision moment. A leave confirm cannot fire; there was no leave. The only thing that survives is writing the gap to durable storage before the interrupt. Memory-only dies with the process. Recovery has to be seen and confirmed: silently applying the draft over the official copy overwrites “I already changed this on another device”; silently dropping it looks like the product ate the work. A prompt on open—“unpublished edits found”—returns the choice. The draft must bind to the same object and the same identity, or Jia’s unfinished sentence lands in Yi’s document. A draft that expires in minutes is absent for someone who comes back hours after a crash.

Studying it

Change a paragraph in edit mode, force-kill or drop the network, open the same object. Compare: no draft, draft applied silently, draft offered with confirm.

Independent variables: when the draft is written (keystroke / timer), whether restore confirms, whether draft time is shown. Dependent variables: recovery after interrupt, mistaken overwrite of the official draft, treating someone else’s draft as one’s own.

Lab kills are cleaner than field crashes; include a delay before reopen. Do not mix with a back-button prompt. On two devices, a phone draft versus a desktop official copy should still produce a confirm.

Where it stops holding

A document already synced on every key has no gap; a restore prompt is noise. Secrets (passwords, payment) must not enter drafts. A read-only view that is killed has no edit gap. If a collaborator already rewrote the same span, restoring the draft is a conflict, not a silent apply. Private mode with no storage should say on entering edit that closing the window loses work, not pretend a draft exists.

Applying it

• During edit mode, write the gap on a timer, bound to this object and this account. On the next open, prompt “unpublished edits,” show the time, and let people restore or discard.
• Do not silently apply a draft over an official copy that has already moved on.
• Keep drafts for hours or days, and say how long remains in the prompt.
• Verify: change a paragraph, kill the process, reopen. People should see a timed restore choice, and the words should return if they accept. Change the official copy on another device first, and confirm restore asks instead of covering.

Related

• Within the group: H8.09.1 Edit and view modes need a readable visual split · H8.09.2 The edit entry appears only when the person may edit · H8.09.4 One person’s edit mode must not hijack others’ viewing
• Adjacent: H1.08 Draft Autosave · H8.01 CRUD Operations · H3.09 Crash and Offline Recovery
• Search terms: draft recovery · crash recovery · unsaved edit