An error page must not throw away what the user already typed

What it is

After a submit or save fails, swapping the whole view for an error page is a good way to throw away words that never reached the server. Not losing what was already typed means the failure surface cannot be bought by destroying the local draft. People can face a failure; they cannot be asked to retype ten minutes of editing. This leaf is not about how to classify the error. It is about whether the failure surface ate the copy.

Why it happens

In a single-page app, a route-level error is often implemented as unmounting the current tree and hanging a static error page. Unmounting drops uncontrolled input, caret position, chosen files. People remember writing, cannot find the words on the error page, and the cost of failure shifts from “try again” to “the work is gone.” Even when the server never received it, the bytes are usually still in memory; loss is the UI choosing to throw that memory away. A real refresh or a real navigation would physically clear it; an error page that imitates navigation misuses navigation’s destroy semantics. Keeping the draft gives retry something to send and back something to save, so the error page’s two exits connect to work already done.

Where it stops holding

Content that must not stay on the device for security (a password on a shared computer, a one-time key) should clear on failure, and say so beforehand. Some platforms will not let a program remember a file-picker path; the error page should at least say “choose the file again,” not pretend the file is still attached. In a multi-user edit conflict, what is kept is the local version, and the server version still has to be visible—not one copy hidden. Session-expiry errors often come with an identity switch; the draft should land in a safe hold before login is demanded, rather than a login view shoving the form off.

Applying it

• On submit failure, do not unmount the view that holds input; show the error on the form, or overlay the error page on a form that is still alive.
• If a route change is unavoidable, write the draft to recoverable storage first, and offer “return to edit” that brings the text back.
• Retry should send the copy that is still local, not an empty form.
• Verify by typing a distinctive sentence, pulling the network, and submitting. If the sentence is gone, the error page is punishing labor already done.

Related

• Within the group: E6.10.1 An error page must offer a way back and a way to retry · E6.10.2 Separate network, permission, and server failures
• Adjacent: E6.14 Offline and connectivity notices · E2.18 Rich text editors · E6.13 Inline result presentation
• Search terms: preserve draft · submit failure · lost input