Skip to content

Instantly share code, notes, and snippets.

@leidegre
Last active March 1, 2021 15:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save leidegre/b1d01b61693bd596bb7e58ac25222427 to your computer and use it in GitHub Desktop.
Save leidegre/b1d01b61693bd596bb7e58ac25222427 to your computer and use it in GitHub Desktop.
The neverending story about autofill in Chrome

The autofill is overlaying my web component and atemptting to insert my home address into this field which is a database configurator, it has nothing to do with my home address. So why can't I get rid of it!?


Background

The issue here is with autofill. The feature in Chrome that fills in form data for you. It's great when it works but it doesn't always work and nobody thinks its reasonable to expect the browser to ever get it right, every time. There's simply not enough context. And for some reason the Chrome/Chromium dev team is stonewalling on this issue, despite the fact that they are making life really difficult for a lot of people. It is as if they have a religious stance on this issue. Every response from a Google or Chromium person fails to capture just how much they are pissing people of with this nonsense.

Problem Statement

Diligent feedback from frustrated human:

Google,

I understand your concerns about autocomplete="off" being abused in many forms, but honestly, I couldn't care less - and it's not your responsibility to fix that.
Your misguided attempt to fix badly coded forms that abuse a perfectly valid feature, is now completely breaking a very large number of high-quality, standards compliant form control libraries and business critical web apps - and even causing security incidents by exposing previous input that should not be exposed.

Please recognize and respect that not all websites are simple shopping sites with simple checkout forms. There are literally millions of sites hidden behind logins, that are highly complex, business critical web apps, build for specialized purposes, for which autofill and autocomplete are very much unwanted features, for very valid reasons - and in some cases, they even pose security risks.

Additionally, there's a very large number of form control libraries out there, providing things like custom date selectors, autocompleting search inputs, and other specialized inputs - some of which are highly domain specific, and some of which provide their own specialized autocomplete UI.
Many of those inputs rely on autocomplete="off" on their inner <input> element, and by breaking that, you are now ruining the user experience of a very large number apps that rely on those libraries.

This is completely unacceptable, and one of the most incredibly stupid decisions in recent memory.

You MUST support autocomplete="off", as defined in the HTML spec.

---

Also, before you repeat you useless suggested workarounds:

THEY DO NOT WORK

There is no way to reliably disable both Autocomplete (i.e. any previously entered values) and Autofill (i.e. stored information, such as my name or address).

autocomplete="off"
----> disables Autocomplete, but enables Autofill.

autocomplete="anything-else"
----> prevents Autofill, but enables Autocomplete.

adding hidden inputs
----> not reliable, and we can't add hidden inputs for every possible thing, everywhere.
(case in point: right now, you are autofilling my first name into a custom date input, on a page that has absolutely nothing to do with names or addresses - WTF?)

---

Please, fix this mess.

Inane response from some Google person (does not address feedback directly):

I can share a few updates on what we are currently up to:

Today, Chrome classifies fields (i.e. whether and what to fill) preferably based on a combination of form form and field signatures. If those don't find matches, it falls back to looking at field signatures only (calculated from name/id and type). This causes some problems, e.g. in <input type="text" name="name">, the "name" can refer to different concepts (a person's name or the name of a spare part). We have an experiment to disable the fallback, which will reduce false positive triggers. The experimental data looks promising so far.

I am currently looking into giving the user the choice to (permanently) hide the autofill suggestions. This will take some more time because the approach has many dimensions that need to be looked at:

- How to trigger the hiding? - right mouse button menu or (more likely) something in the drop down? where would we put that?
- What is the scope? - the field, the form, the site?
- How can a user recover from the state of having accidentally disabled autofill? - right mouse button menu? implicitly by typing values that autofill would have suggested?
- How can we apply crowdsourcing such that Chrome automatically does the right thing for users?

So in summary:
- I think that once the experiment rolls out, the perceived behavior will improve quite a lot in the short term.
- In the somewhat longer term there should be more controls.
- Overall, I still believe that neither of the extreme strategies ("always honor autocomplete=off" and "never honor autocomplete=off") are good.

Which again, reaffirms the problem here, there's a belief within the team that they can fix this by some other means -- and while they keep failing at that -- they refuse to offer sensible alternatives.

Which leads to even more frustration like this, (which I fully understand and respect).

You are breaking our products, pissing off our customers, refusing to adhere to the spec, and suggesting insane workarounds that do not work reliably.

Note that this has been a standing issue with over four years of history. Despite the hundreds of people that have submitted their respectful feedback on this issue, somehow, this is still a problem in 2021.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment