Autofill results must remain manually overridable

What it is

A value the browser filled is a default from a profile, not the final state of this task. Manual override means people can immediately edit, delete, or paste another string, and submit is what remains after that change. Scripts must not write the value back to the filled result on blur, before submit, or during “formatting.” An application locking its profile as read-only is a locked-prefill problem. Here the lock comes from the autofill pipe: some pages rerun fill on change, some forbid typing in a filled field, some formatters rearrange by the old profile. Which source wrote first does not cancel override.

Why it happens

Autofill is never perfectly accurate: the profile is stale, it landed in the wrong field, this shipment goes to someone else. Override is the only in-place correction. A second layer is override silently undone. People change the house number; on blur a script requests “canonical address” again and the value snaps back to the profile. Or a mask rewrites by card rules and cuts a newly pasted card back to the old one. People think they changed it; submit is still the filled value; memory and payload split. Forbidding paste, or setting readonly after fill, declares the profile unquestionable. Override must also cover a whole group: change only the street, leave the old city, and fulfillment is still wrong. A clear-this-group control (“don’t use this fill”) is often safer than editing cell by cell.

Studying it

Have the browser fill an address; the task is to change it to another. Compare direct edit, snap-back on blur, paste forbidden, readonly after fill.

Independent variables: whether a script writes back after override, whether paste and select-all-delete are allowed, whether “clear this filled group” exists. Dependent variables: whether submit is the overridden value, whether people think they already changed it, time to change a group, snap-back count.

If snap-back is fast in the lab, participants think they failed to edit and try again, polluting time. Read the submit payload in the network panel or logs, not only the screen. Turn off app-prefill writeback so two writebacks are not stacked.

Where it stops holding

When a payment rail tokenizes a card on recognition and the box becomes a display mask, override should happen before tokenize, or offer “use a different card” rather than editing two digits on the mask. An enterprise-locked browser profile that forbids override this time should say “provided by company profile” outside the field, not pretend to be editable autofill. Read-only display fields were never fill targets. Speech override and keyboard override should share one value pipe, so speech is not covered again by keyboard fill.

Applying it

• After fill, keep the field editable, pastable, and select-all-deletable. Do not cover the user’s just-written string with a profile value on blur or before submit.
• Formatting may tidy punctuation and case. It must not replace the value with another profile record.
• For grouped fields such as address and payment, offer “clear autofill” for the group, not a half-new half-old leftover.
• Verify: after a profile address fills, change the house number, blur, and confirm the payload is the new number. Paste a whole new address. Use a blur writeback as a counterexample a release check must catch. Compare on-screen value and payload; they must match.

Related

• Within the group: H1.13.1 Browser autofill and in-app prefill have different sources and must be handled apart · H1.13.2 Nonstandard field names make autofill land in the wrong fields · H1.13.3 Autofill into hidden fields can harvest data and must be scoped
• Adjacent: H1.09 Smart prefill · E2.17 Clear buttons in fields · E2.21 Read-only, disabled, and non-editable
• Search terms: override autofill · autocomplete · paste