Browser autofill and in-app prefill have different sources and must be handled apart

What it is

Browser autofill writes names, addresses, and accounts from the browser or password-manager store into fields tagged with matching semantics. The data owner is the user’s browser profile; the application does not know in advance what will be filled. In-app smart prefill writes the application’s own profile or orders into fields; the data owner is this product. Both can happen at once: the app writes last address at render, the browser writes another address on focus. Handling them apart means source cues, override rules, off switches, and blame for errors cannot share one sentence or one toggle. Wrong field names, fill into hidden fields, and the user’s right to override are the other three items in this group.

Why it happens

Autofill mapping is decided by the browser on focus or at parse time. App prefill mapping is decided by the server or a script at render. People see characters in a box and cannot tell “this shop remembers me” from “my browser remembers every shop.” A second layer is who wins a conflict: the later write covers the earlier. If the app prefills on DOMContentLoaded and the browser fills when the user clicks into the field, the browser wins. If the app scripts another profile write after autocomplete, the app wins. People cannot predict which address they wanted. Turning off “remember me” only stops app prefill, not the browser; turning off browser autofill does not stop the app profile. Treating both as one feature on a settings page makes the switch lie. Payments and sign-in add a password manager as a third store, which also cannot share one “smart fill” switch with the app profile.

Studying it

Build pages with app prefill only, browser fill only, and both on with different addresses. Record which store is submitted and which store people think it was.

Independent variables: both stores enabled, write timing (render / focus / script again before submit), whether settings split into two switches. Dependent variables: source of the submitted value, accuracy of source judgment, whether the other store still writes after one switch is off.

Lab machines with browser fill off will look like app prefill only. Measure on a real browser with a password manager on. Do not count mismatches into the wrong field as “source conflict”—that is a naming problem.

Where it stops holding

When the app has no account and has never prefilled, only the browser store exists; no app-side switch is needed. When an enterprise-managed browser disables autofill, app prefill is the only source and blame sits entirely on the app. A page inside a WebView may not get system fill and will look like “autofill is broken” when the shell never connected the manager. Native system fill (iOS Password AutoFill) is another pipe from HTML autocomplete; mobile shells must be tested separately.

Applying it

• Split the two sources beside the field: app prefill as “from your profile on this product,” browser fill left to the system’s key or highlight. Do not call both “smart fill.”
• State a conflict rule and run it once: e.g. browser fill on focus beats app prefill at render; no script may write again before submit.
• Two switches in settings: stopping app prefill ≠ stopping browser autofill.
• Verify with different profile and browser addresses: click into the address field and check which store remains and whether copy names it. Turn off only app prefill; the browser must still fill. Turn off only browser fill; the app profile must remain. Script another profile write before submit as a forbidden control.

Related

• Within the group: 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 · H1.13.4 Autofill results must remain manually overridable
• Adjacent: H1.09 Smart prefill · E2.16 Autocomplete dropdowns · O1.01 Privacy by design
• Search terms: autofill · autocomplete · prefill