Browser autofill puts the wrong information in checkout fields

Record the wrong type of information without copying its value

Start with the actual checkout step and field label from the report. Record the expected purpose and the observed information category, such as company information, a person's name, a telephone value or an address component. The category can establish a purpose mismatch without copying the buyer's name, number or address into a shared worksheet.

Distinguish browser autofill from information that was already populated when checkout opened or appeared after a different checkout action. Note when the value changed and what action immediately preceded it. A wrong value on the page alone does not establish that browser autofill supplied it. Record browser name and version, device and checkout path so the maintainer can examine the same behavior rather than a different form.

Compare the visible instruction with the input's exposed purpose

W3C's Labels or Instructions guidance requires labels or instructions for required input, but explains that programmatic association is a separate accessibility concern. This distinction matters here: the words a person reads and the association between those words and the field both need inspection. Renaming the visible label alone does not show that the field's software meaning changed.

MDN describes autocomplete as a hint about the expected value and purpose; the browser chooses the source it uses. Ask the maintainer to inspect the rendered input, its label association and its autocomplete setting after the checkout has reached the reported state. If a field has no own autocomplete setting, the owning form's setting matters. Record the actual field and form settings instead of assuming the editor's label describes the final markup.

When the visible label asks for one category but the rendered hint identifies another, there is a concrete semantic mismatch to repair. If the label, association and hint all match the intended purpose, the observed wrong value remains real but its cause is unresolved. Compare the user's selected autofill entry and any other component that populated the field before deciding which party owns the defect.

Check grouping and phone purpose without promising browser behavior

MDN documents billing and shipping tokens for address groups and section-* tokens for distinguishing repeated groups. Identical token lists can receive the same data. If several fields unexpectedly receive the same kind of information, inspect whether repeated groups expose indistinguishable hints. Use grouping that matches the actual form purposes; do not add arbitrary distinctions without identifying what each group represents.

Phone fields need a purpose comparison as well. MDN distinguishes tel, which includes a country code, from component tokens for parts of a phone number. Check whether the form expects one full number or separate components, and compare the actual hint with that design. The hint does not validate the value or prove that it belongs to the buyer. A format error after filling and a wrong-purpose fill are different observations, even when they occur in the same field.

Browser prerequisites and behavior vary, so valid hints do not establish universal autofill success. Nor is turning autocomplete off a universal remedy: MDN notes that it does not universally prevent password-manager autofill. Use a confirmed purpose or grouping defect to guide a targeted repair instead of asking every buyer to change saved information before the form has been inspected.

Make the repair observable in the affected checkout

Give the implementation owner the visible label, expected purpose, observed type, rendered settings and browser details. Identify which theme, extension or hosted component supplies the field from the actual implementation record. The repair request should say which mismatch needs correction and which ordinary manual-entry behavior must remain usable. A broad checkout replacement is not established by one autofill observation.

After an authorized repair, observe the same autofill action on the affected checkout and browser, using information the person performing the check is authorized to use. Stop before submitting an order or payment. Record whether the expected information category now enters each field and whether it remains editable where intended. A successful observation is limited to that environment; it does not certify all browsers or validate buyer identity. A Prism checkout-review consultation can discuss the finding and requested help, with scope, responsibilities, fees and terms confirmed before work.

Autofill-purpose review

Complete one sheet per affected field and checkout path using an actual observation. Record information categories, not personal values. A mismatch between intended purpose and rendered semantics supplies a repair target; matching semantics with a wrong result leaves the cause open for investigation.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.