The Dialog That Asks Whether to Save Is a Bug Report

A save prompt is the app admitting it does not know what you want. Writing it more politely does not help. In a field experiment on 80,000 users of a privacy tool, polite requests and buttons pointing at a voluntary decision decreased the probability of consent ¹. The dialog is not a wording problem. It is a design one.

Rainer Böhme, then at ICSI Berkeley, and Stefan Köpsell of TU Dresden published it at CHI 2010: one consent dialog, shown in a 2 × 2 × 3 grid of variations ¹. Three things changed across them, by the abstract's account — how politely it asked, whether the button text pointed to a voluntary decision, and how closely it resembled a licence agreement.

Every courteous dimension made it worse. People were not reading the sentences — they were recognising a shape they had already learned to dismiss ².

The three-button question, and why its buttons are the wrong words

Yes, No, and Cancel are not answers — they are placeholders for answers. Which one destroys your work depends entirely on how the question was phrased, and the question is usually one line long. Martin Kleppmann named the problem in 2007, and the buttons have not changed since.

"The meaning of these words depends very much on the question," he wrote. "In fact, if you have no previous computing experience, you will probably have no idea what to answer." ³

They are not ambiguous in the abstract. They are ambiguous at the one moment that matters. "As a user, you just want to know which button is going to cause your work of the last 2 hours to be lost," Kleppmann continues, "and neither of these examples makes it immediately clear which the 'dangerous' button is." ⁴

Platform guidance says what to do instead. GNOME's Human Interface Guidelines classify this object: "Print and Save dialogs are classic examples of action dialogs." ⁵ Their rule for its buttons runs one sentence: "Label the affirmative button with a specific imperative verb, for example: Save or Print." ⁶

A verb tells you what happens. Yes tells you nothing.

A save dialog, before and after

The fix is not a better sentence. It is a different set of buttons in a different order, each labelled with the verb it performs, with the destructive option named for what it destroys and the default key bound to the safe one. Here is the same dialog written twice.

BEFORE
  Title:    Save changes?
  Body:     Do you want to save the changes you made?
  Buttons:  [ Yes ]  [ No ]  [ Cancel ]
  Return:   activates "Yes"
  Escape:   unbound

AFTER
  Title:    Save changes to "quarterly-review.md" before closing?
  Body:     Your edits from the last 12 minutes will be lost
            if you discard them.
  Buttons:  [ Cancel ]  [ Discard Edits ]  [ Save ]
  Return:   activates "Save"
  Escape:   activates "Cancel"

Four things changed, each with a rule behind it: the buttons became verbs ⁶; cancel moved to the front, because that ordering "ensures that users become aware of, and are reminded of, the ability to cancel prior to encountering the affirmative button" ⁷; No became Discard Edits, the only way the dangerous button is identifiable at a glance ⁴; and the keys were bound on purpose, Escape to cancel and Return to the affirmative ⁸.

That last one is where real dialogs fail. Invert the question to Discard changes? and the affirmative button becomes the destructive one, so the default key throws work away — which the guidelines forbid outright: Return should not activate a button whose action "is irreversible, destructive or otherwise inconvenient to the user." ⁹

Both blocks are composites, not screenshots.

The surprise: writing it more politely made it worse

Courtesy is the intuitive fix and it is the wrong one. In Böhme and Köpsell's field experiment, polite phrasing and buttons that offered a genuine choice both lowered consent, against what social psychology predicted. The abstract's explanation is that people were processing the dialog's shape rather than its sentences.

It names the mechanism, and the culprit: "Participants seem to be habituated to coercive interception dialogs — presumably due to ubiquitous EULAs — and blindly accept terms the more their presentation resembles a EULA." ²

The politeness effect did not vanish. It was outvoted: "subtle positive effects of polite requests indeed exist, but stronger negative effects of heuristic processing dominate the aggregated results." ¹⁰

Heuristic processing is what every writer does with a save prompt at 1 a.m. You are not evaluating a question. You are clearing an obstacle.

What the researchers actually measured

Two brain-imaging studies measured attention to a repeated on-screen warning, and both found the collapse happens almost immediately. Anderson and colleagues recorded a drop in the visual processing centres of the brain after the second exposure; Vance and colleagues watched the same drop repeat and deepen across five working days.

The 2015 result is stated without hedging: "Our results show a dramatic drop in the visual processing centers of the brain after only the second exposure to a warning, with further decreases with subsequent exposures." ¹¹

The 2017 replication moved it into a working week, measuring with an fMRI scanner and an eye tracker at once. It found "a dramatic drop in attention in terms of neural activity and eye fixations after only the second warning exposure, with further decreases throughout the workweek." ¹² That sentence rests on 11,976 eye-tracking observations ¹³.

Field telemetry has the same shape at a scale no lab reaches. Devdatta Akhawe and Adrienne Porter Felt observed "over 25 million warning impressions in situ" ¹⁴, with users clicking through 49% of untrusted-issuer warnings within 1.7 seconds and 50% of name and date errors within 2.2 and 2.7 seconds ¹⁵. They read it as warning fatigue: "users click through more-frequent errors more quickly." ¹⁶

All of that measured a security warning. The closest evidence to a save prompt is a Carnegie Mellon experiment that deliberately left security behind: because repeated exposure would have given the game away, the team built "a new experimental design in which attractors would not be used in a security context." ¹⁷

What remained was a plain dialog, repeated until it was furniture, with one field changed near the end. The metric is defined precisely, so the number can be quoted: "the proportion of users who click the 'No' option on the first trial of the test period." ¹⁸ On it, treatments that physically inhibited dismissal ran between 44% and 74%, "as opposed to the non-inhibitive treatments which reached a maximum of 20% for Short ANSI." ¹⁹

A follow-up the next year found the causal version: "increasing habituation caused a three-fold decrease in the proportion of participants who responded to the change in the dialog." ²⁰ It also recorded the visceral detail: "Nearly 75% of participants using the Swipe treatment were able to dismiss the 20th habituation dialog within five seconds." ²¹

By the twentieth showing, a dialog is not being read. It is being cleared.

Who owns the words in that dialog — and it is not the app

A web app cannot write its own unsaved-changes message. The HTML Standard makes the wording the browser's: the page can request a prompt, but the text is the user agent's, and the value the page supplies is discarded. Roughly six in ten Chrome page loads arm that request.

The specification is unusually blunt: "the message shown to the user is not customizable, but instead determined by the user agent." ²²

Five conditions must all hold before the prompt appears at all. No prompt has been shown yet for this navigation; the document is not sandboxed against modals; its global object "has sticky activation," so a tab you never touched cannot detain you; the page signalled that it wants one; and showing it is "unlikely to be annoying, deceptive, or pointless." ²³

A browser reserving the right to judge a dialog pointless is a design verdict written into a standard. The page's only lever is a historical wart: returning false from a handler normally cancels an event, and the standard lists exactly two exceptions to that rule — this is one of them ²⁴. You may raise your hand. You may not choose your words.

Nor is this rare: registration of the handler runs at a 58.52% median of Chrome page loads over the 30 days ending 24 August 2026 ²⁵.

It is also not going away — worth saying plainly, because a neighbouring event is. Chrome is retiring unload, a different event that produces no prompt at all, and that rollout reached 80% of Chrome page loads at milestone 152 on 25 August 2026, with 100% scheduled for milestone 154 on 22 September 2026 ²⁶.

Across eight years of the same counters, unload registration fell from a 62.13% July median in 2018 to 15.39% in July 2026, while the unsaved-changes handler held flat, 55.43% to 58.02% ²⁷. The web abandoned one and kept the other.

Five changes to make before your next release

None of these require research. They require deciding that a reader's attention is not yours to spend. Take them in order of what they demand: two are relabelling, one is a keyboard binding, one is a feature you may not have built, and the last is an architecture decision.

1. Replace Yes, No, OK and Done with the verb. Save. Discard Edits. Keep Editing. Each button should read correctly without the title above it ⁶.
2. Put cancel first, affirmative last. The stated reason: a reader meets the escape route before the commitment ⁷.
3. Bind Escape to cancel, and never bind Return to a destructive button. If no button is safe to default to, set no default at all ^{8 9}.
4. Ship undo instead of the question. In GNOME's words: "Since users will often habitually click through confirmation dialogs without fully reading or considering them, undo is typically a better option than a confirmation dialog." ²⁸ It also "avoids interrupting the user" ²⁹.
5. Remove the reason the question exists. Chrome's guidance names the moment: "Consider the hidden state the last reliable time to save app and user data." ³⁰

Only the last is architecture. The other four ship this week.

The caveats: what this evidence does not prove

None of the brain-imaging work measured a save dialog. It measured security warnings, and the transferable claim is the mechanism, not the percentages. The samples are small — 25 people in one scanner study ³¹, 15 in the other ³² — and attention partially recovers overnight, which the researchers say themselves.

They are not alone, which is what makes the pattern hard to dismiss: the same 2015 paper carries a behavioural arm with "analyzable data from 76 participants across 1,466 warnings" ³³, and the two dialog experiments finished 872 and 2,567 participants ^{34 35}.

The recovery finding cuts against the argument and belongs in it: "We found that participants' attention partially recovered between workdays when the stimulus was absent." ³⁶

Attention comes back overnight. Then it drops again.

One number should not travel. Akhawe and Felt found users "continued through 70.2% of Google Chrome's SSL warnings" ³⁷ — a security decision with a visible reward for ignoring it, and nothing here says the same share discards unsaved work. And only the CHI 2010 abstract is public, so every claim drawn from it above is an abstract-level read.

The best save dialog is the one the app never needs

A prompt exists because the app is unsure whether the work is safe. Remove the uncertainty and the prompt has nothing to ask. Chrome's own guidance says to treat the moment a page becomes hidden as the last reliable time to save — not the moment someone tries to leave.

The vendor is direct about the limits of asking. The unsaved-changes event "is often used to warn users of unsaved changes when navigating away," but "is also unreliable as it won't fire if a background tab is killed," so the recommendation is to "limit use" of it ³⁸.

A dialog that does not fire when a phone kills your tab is not a safety net. It is one that works on the days you did not need it.

So the design question moves. It stops being what should this dialog say and becomes where does the work live between keystrokes. A note already written down — in a plain file, on your own device, in a format that opens without the app that made it — has no pending state for a dialog to negotiate over.

That is not a promise that nothing can go wrong. Storage fails and people delete things — so an editor built this way still owes you a way back to yesterday's version, somewhere to recover what you deleted, and ideally a record that appends rather than overwrites. Those are recovery. A modal question is not.

One other dialog still earns the name: in the encoding menu, choosing UTF-8 without a byte-order mark decides whether the file is readable in ten years. That question is genuinely yours.

Every modal an application shows is a decision it declined to make. The save prompt is the most revealing, because it arrives after you have already said what you want by closing the window. Text that is already a file does not need to be asked.

MNMNOTE keeps notes as plain Markdown on your own device, works offline, and shares by end-to-end encrypted link — so whether the work is written down is settled before you close the tab: mnmnote.com.

Frequently Asked Questions

Short answers to what people actually type when a save prompt annoys them, drawn from the specification, the vendor documentation, and the studies above. Where a number came from a study of security warnings rather than save dialogs, the answer says so — rather than leaving you to find out.

Is it possible to display a custom message in the beforeunload popup?

No. The HTML Standard says the message "is not customizable, but instead determined by the user agent," and that "the actual value of the returnValue attribute is ignored." ²² A page-authored message would be an attack surface. The browser also refuses the prompt unless showing it is "unlikely to be annoying, deceptive, or pointless." ²³

Should a note app ask me before I lose unsaved changes?

It should not need to. Chrome recommends limiting use of the unsaved-changes event, because it will not fire when a background tab is killed ³⁸. A prompt unreliable on the very failure it exists to catch is not the fix. Saving earlier is.

Is Chrome removing the unsaved-changes prompt?

No. Chrome is deprecating unload, a different event that shows no prompt. The unsaved-changes handler is not being removed — Chrome's counters show it flat, from a 55.43% July median in 2018 to 58.02% in July 2026, while unload fell from 62.13% to 15.39% ²⁷.

Why do I keep clicking through warnings without reading them?

Habituation. Brain activity in the visual processing centres drops "after only the second exposure to a warning," ¹¹ and across more than 25 million field impressions, "users click through more-frequent errors more quickly." ^{14 16} Those were security warnings; the mechanism carries over, the percentages do not.

Is a confirmation dialog better than an undo feature?

Usually not. GNOME's guidelines say that because users "will often habitually click through confirmation dialogs without fully reading or considering them, undo is typically a better option". ²⁸ Keep the dialog only where undo cannot be offered.

What should the buttons on a save dialog say?

Imperative verbs naming what each does — Save, Discard Edits, Cancel — with cancel placed first ^{6 7}. The destructive option should name what it destroys, and Return should not activate a button whose action "is irreversible, destructive or otherwise inconvenient to the user." ⁹