Agenda item: Signal to the browser that a certain field should not be autofilled

[yoavweiss]

There are many cases of abuse where developers are attempting to turn off autofill with no legitimate reason.

But there are other cases where the potential autofill UI is in conflict with the developer's intended UI for the field.

For example:
Imagine a pickup address field where the user needs to choose a pickup address. The addresses are known to the server (as these are addresses of pickup service providers), and not necessarily known to the browser.
Yet the browser (or autofill provider extension) might detect the "address" part of the field through various heuristics and try to fill it as the user's address. In terms of UI, the autofill UI may overlay on top of the developer provided UI, preventing the user from interacting with it.

This is obviously an issue, but today there's no standard way for developers to prevent this (beyond various hacks, which may or may not work across different browsers and autofill extensions). It'd be great if there was one.

[mdentremont]

Here is an example of how it can lead to poor UX:

[jtrollia]

Interesting 👀 I assume it's limited to specific apps? This is the default/native UX when I try local pickup on my shop: Google autocomplete shows up and I see no autofill suggestions

[asalisbury]

Parsing some of https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill, it sounds like there's something worth tightening up here even if the above example might not in practice be an issue...

Setting autocomplete to "off" doesn't necessarily prevent autocomplete. Some browser vendors have made the choice that letting users rely on saved passwords matters more than honoring a site's request to suppress autofill on login fields. For address fields though, not sure. Given they often use heuristic-based address detection, an unrecognized autocomplete value may not be enough to suppress autofill on fields that look like address fields to the browser.

A value like "none" (which is what the above example with the checkout pickup location address input uses) is not a recognized token. Per the spec, this falls through to the default behavior, which is equivalent to "on" (heuristic-based autofill). However, in practice, browsers can't map an unrecognized token to a specific data type, so they typically have nothing concrete to suggest. This makes it a widely-used de facto hack, but it's not a spec-guaranteed behavior. It sometimes works because of current browser implementation, but not because the spec says unrecognized values disable autofill. Browsers could theoretically still apply heuristic autofill to these fields.