Unfortunately, the decision to ignore the autocomplete attribute also makes it very hard to help the browser pick up the appropriate autofill username/password fields.
All browsers right now basically assume that if you have an input type="password", then the previous input type="text" must be the username field. And there's little you can do to change this without resorting to substantial hacks like using a hidden username-looking honeypot field to eat the poor browser behavior.
For example, imagine a pop-up confirmation box that asks you for your password before continuing. Or really just a "confirm password" field on any form. It can be very hard to get browser or extension password autofill to only affect that one field and not inject a username into some other field on the page. Password managers in browsers and extensions are surprisingly brain-dead, and they give us no tools to help them out.
To put UX first, especially around something as UX-sensitive as password autofill, you end up needing to put in a lot of extra work to make up for the browser's confidently-wrong implementations.
The original decision to ignore autocomplete="off" was probably the right move. But now that the autocomplete attribute has been overloaded with password manager concerns built in to web browsers these days, nobody has bothered to revisit the ordeal.
That's interesting. I almost never see "please enter password to confirm" but I always see (the more annoying) please enter username and password to confirm. Now I know why.
It’s pretty incredible to see the amount of steaming developers commenting on this issue. What tools do developers have, when platform providers turn a deaf ear to their needs?
The problem is that you’re only seeing angry developers and not the angry users frustrated that they can’t use autofill on sites that disable it for no real reason. Sites being able to change the behavior of the user-agent is almost always a bad thing.
autocomplete=off should just be removed and it be entirely up to the user-agent whether it gets used like reader mode.
Well.... As a user of forms that intentionally add autocomplete=off so that their own autocomplete forms show instead, it is very not good to see both autocomplete mechanisms compete with each other.
Alternately: User-agents changing the behavior of well-written sites without user knowledge is almost always a bad thing.
Giving the user more control is great: things like reader mode, option to disable auto-play video or options to kill resource-intensive scripts. This isn't a tool for the user, it is the browser's behavior whether the user wants it or not.
If autocomplete=off is user-hostile, then it should be changed in the spec. The spec gives a few use cases (site has its own autocomplete, field is sensitive information that shouldn't be cached, field is a one-time key). If autocomplete=off is removed, how would those cases be handled?
You've got to consider the 2nd order effects. Remove autocomplete=off? Developers will be forced to make their own DIY crappy text inputs just to get rid of it. And break everything but English input in the process.
I mean sure but there’s no reason this can’t occupy the same space as the other website toggles like reader mode and permissions.
I think these features should be like the notifications pop-ups “This site requested that Chrome not automatically fill out forms. Tap here to enable autofill anyway for this site.”
I've had several of our users call up over the years, angrily asking why we made certain fields in our app "dropdowns" with rubbish in them.
Chrome decided to add autocomplete to some of our fields with contextually irrelevant options. As far as I know there isn't anything I can reliably do about it.
The browser can (and should) totally disregard what the webpage says if the user tells it to. The default should never be "break websites without asking the user".
I was asked by my users of an internal tool to disable autocomplete. I added autocomplete="off" and autocorrect="off" (spell checking makes no sense for this field), and it was disabled, including for chrome users.
Am I missing something? Is there some sort of heuristic to when it actually disables that I just got on the good side of by pure luck?
> Am I missing something? Is there some sort of heuristic to when it actually disables that I just got on the good side of by pure luck?
Yep, you are.
Chrome will fill in fields by not just looking at the autocomplete attribute, but also by trying to magically infer it based off the name attribute (and other heuristics).
For example, if you have a text entry box for a filename, and happen to set "name='name'" on it, even with autocomplete off you will get a pick list of people's names.
Thanks, Chrome. So many sites have user-hostile code that is overridden by this choice. I still remember the glee when I first started using Chrome all those years ago, and suddenly all those forms filled themselves out.
I’ve seen autocomplete create plenty of problems. It can break some (admittedly poorly designed) forms outright. Or in others simply create a bad user experience. There are lots of forms that ask for an address but that should never be autocompleted to the user’s address.
In practice as a developer you have to resort to JavaScript hacks and obfuscating form field names to avoid it.
I really really wish there was a way (holding shift, ctrl or something) to only autofill the one field without it goig to fill/replace every other field on the page. It's so annoying when the stuff you just field get replaced just because you want to autofill one field.
My favorite is when it autofills a whole form that has the field name only as a hint that disappears once it's filled. Of course it always fills with the wrong set of information.
I typically type everything manually in long forms because the autofill tends to get something wrong every once in a while. It's like choosing to drive the car myself rather than trusting the self-driving feature.
I figure most people just tolerate wrong inputs and live with the results. (It doesn't happen that often.)
> It's very hackish way but I found a trick to achieve the same.
> So you should go to chrome://settings/addresses?search=address
> Now create multiple addresses, each with only one field filled. So one should only have your E-Mail, another record should contain only your first name only, and so on.
But any new code that's being written just finds other ways to avoid autocomplete. Ignoring autocomplete=off makes the web a bit less standards compliant for a a very short temporary benefit.
I'm the developer of a Virtual Terminal web page which allows a merchant to accept credit card payments. I would love to turn-off autocomplete for the credit card details. The person using the Virtual Terminal wants to type in someone else's card number, not use their own every time.
The PCI-DSS council is partly to blame here, for recommending autocomplete=off in other contexts.
Why do they even do that? What’s so bad about pasting into a form? Does the person who designed the form think your password isn’t secure unless it is written on a piece of paper kept in a bank vault?
Especially when I'm pasting my routing number or bank account number.
Like are you kidding me? I went into my bank app/website, I used the "copy" feature, and I'm trying to paste here AND into your "confirmation" field. Because I don't want to typo it!
How could my copy skill be worse than my typing skill?
I'm on board with not allowing paste into a confirmation field since you might have copied the wrong number so there's nothing to gain from confirming the same mistake. Imagine you're doing several transactions and on one of them, you don't quite press the copy key correctly and end up using the previous account number from the clipboard.
While we're complaining about pasting, am I the only one who gets annoyed by sites that only have click to copy buttons for certain content? It's often either that or they try to help me out by highlighting it. What I really want is to highlight it myself so I can paste it into my terminal. It'd be great if there was a way to get the button click copies to go to my other clipboard but I can't find anything on it anywhere
It's pretty easy to make a website that has things that look and act like text inputs but which cannot be pasted into and cannot be detected as text inputs by the browser (short of something like computer vision, which I doubt will work well in practice).
I have been asked, by users, to turn off the autocomplete. I managed to do it by a hacky "change the id every time to a random new name then change it back upon submission" piece of js that I disliked. I wish I had known about the autocomplete=nope option.
I’m not sure, but this might be related to my issues whenever I used chrome, and it would auto fill hidden elements of settings forms in pfSense. All of a sudden you had changed stuff you didn’t mean to, or get seemingly weird errors about invalid input.
At least I could imagine this prop being applied to hidden elements, either in pfSense or internally in chrome.
I took our CI/CD pipelines offline when I edited one form in the CI/CD users admin panel, and Chrome autocompleted a hidden form, disabling various permissions. :/
GOOD! Acting like a user agent, as it should be! If only there was also a way to cause unending pain to anyone who created those nasty "do not paste in here" javascript tricks too..
That's great that Chrome happens to work as you like, but I am also a user and hate this behavior. How do I get Chrome to function as a user agent in this regard?
As a user, I think Chrome ignoring autocomplete=off is great and if it was a flag, I would enable it without hesitation. This feature is misused all the time.
How do you feel about the examples given in the thread like autocomplete suggestions overlaying a datepicker? Surely that's not great for anyone.
It may well be that disabling autocomplete is open to abuse, but it's not up to the browser venders to police the quality of webpages. There are plenty of other features that are abused all the time. Should browsers disable window.onscroll because it can be misused? How about all of JavaScript?
Chrome is extremely anti user choice. They have a very "we know better than you" attitude. There is about:flags but most flags are temporary and are eventually removed.
I have mixed feelings. I get the user agent argument, although it's hilarious to hear people say this about Chrome. My biggest pet peeve is that websites can decide to not let me use "/" to search in the page. They "cleverly" move your cursor to the search box. I have to use the clunky ctrl-f instead.
But I've also been bitten by autocomplete bugs. It has a strong tendency to make the user do the wrong thing and then forces developers to use silly hacks to stop it. It's not as bad as the IE6 days, but it's not ammillion miles away.
I was a bit shocked when I was hit by this a couple of years back (2017) and learned that browsers are adamant about providing autocomplete, going so far as to infer the type from labels or placeholder strings.
The problem was even more frustrating because it seemed like disabling it was the only workaround to prevent a strange mobile Safari issue where the autocomplete bar would push the "next/prev element - Done" bar, on top of the keyboard, up so it would overlap the "position: fixed; bottom: 0;" element on the page (which was the input the user was trying to write into).
The argument that the user would complain to the browser vendor if he couldn't autocomplete is a bit strange to me. I would think the real novice users would begrudgingly accept the inconsistent behaviour and the users that do care about it would complain to the website they were on. But then again I haven't read any user studies regarding this.
related, is there any way to actually shut it off via Chrome?
I have the password manager disabled (supposedly) and using 1Password, but Chrome's version still pops up on login forms and interferes with 1Password.
It is ironic that so many developers are taking the time to complain on the bug tracker but won't simply write Chrome out of their org. I did that at a place and most of the users didn't even realize something had changed.
No developers seem to have a problem simply refusing to support Firefox. I wonder how much extra effort it is going to take for them to finally make the switch.
This statistic is not without reason. Chrome still has considerable usability and security advantages, especially for non-technical people(at least on anything that's not OS X), and still the best dev tools out there.
We can be lucky that FF at least tries to stick to standards where Safari doesn't bother.
I don't think that's material. If we're talking about corporate policy on corporate-owned machines, employees shouldn't be complaining to IT that their favorite websites aren't working properly in Firefox. If they do, the canned IT response should always be "why are you doing personal tasks on your work machine?"
As long as the corporate/enterprise apps work on Firefox (which they should?), it's not a problem for a corporate IT department to ban Chrome.
Companies also want their employees to be as productive as possible, which are likely already using Chrome at home because it has the best usability and quality of life for non-technical users.
I don't think any IT department worth their while would ban worthwhile software because of some agenda that frankly just doesn't matter too much to most regular users, at least in an US context.
In the EU this might be a bit different, as they would have an interest in getting Google out of their ecosystems - but we've seen that that just doesn't really work too well, with pilots in various governments. People aren't as productive and complain about not having the same Excel and the same Internet as they have at home.
How is expecting things to work "having an agenda?"
For the longest time Chrome would search google first before local DNS for FQDNs. When I reported that years ago they labelled it "wontfix."
In Chrome 69 they started single-sign-on and didn't get around to adding an option to disable until 71. And this autocomplete bug has been a problem for years also.
There are valid reasons to switch. I'm not here to make users feel at home. I'm here to make sure the stack runs on their machine. I find that is easier to accomplish with Firefox.
> Companies also want their employees to be as productive as possible[...] I don't think any IT department worth their while would ban worthwhile software
This shows a disconnect / bubble. Lots of IT departments require permission to install any software, i.e., a whitelist, rather than the blacklist being proposed (and which is fine in this instance). Granted, many of those places don't care about their employees being as productive as possible (even if they tell themselves they do), and their IT departments aren't worth their salt, and this tends to be norm, unfortunately.
> As long as the corporate/enterprise apps work on Firefox (which they should?)
They have even less of a reason to support Firefox. I used to work on an partially enterprise (well, government) program. We dropped Firefox support for it because it was easier to tell the client to just install Chrome. And the complexity of enterprise software means that that will always be easier for the client as well than switching.
Why do forms still have nopaste support then? My bank occasionally makes me type an account number that I've copy/pasted from elsewhere in its interface. :(
It is not just a simple nopaste support, but a paste event listener. I guess back websites just uses preventDefault to prevent pasting. Although this is anti user, but it also has good use cases such as pasting image into a rich editor. Websites like Google Doc do have legitimate use of this feature.
IIUC "nope" used to be effective at disabling autocomplete because it's an invalid autocomplete value which Chrome treats differently from "off" (which it ignores) or "on" (which enables autocomplete). Chrome 81 should already have fixed this quirk.
I think the purpose of autocomplete="off" is to allow an (honest, well-meaning) web site to tell a browser, "I know you think this looks like an address field, but it really isn't".
Unfortunately, in reality, it's probably more often used to force users to type things in for misguided "security reasons".
I think browser UI for this is generally just bad. I think forms should never auto-fill, but when I click on a form field, it should give me a dropdown to select text to put in just that field. Not that field plus all other fields in the form. Just that field. Then you don't have privacy issues (because the site never sees the autocomplete options unless the user actively selects one), and autocomplete="off" becomes unnecessary.
How does disabling auto-complete impact privacy?
There are some examples in the thread - you can't have your address suggestion thingie display without Chrome's autocomplete on top of it.
Ofcourse they won't fix this. Autocomplete saves form values which are usually full of juicy information like addresses, names, ssn's, payment info, etc. which are vacuumed up by the data monster. Same with passwords. Even though the passwords themselves are encrypted it's amazing metadata to know which sites you have accounts for.
All browsers right now basically assume that if you have an input type="password", then the previous input type="text" must be the username field. And there's little you can do to change this without resorting to substantial hacks like using a hidden username-looking honeypot field to eat the poor browser behavior.
For example, imagine a pop-up confirmation box that asks you for your password before continuing. Or really just a "confirm password" field on any form. It can be very hard to get browser or extension password autofill to only affect that one field and not inject a username into some other field on the page. Password managers in browsers and extensions are surprisingly brain-dead, and they give us no tools to help them out.
To put UX first, especially around something as UX-sensitive as password autofill, you end up needing to put in a lot of extra work to make up for the browser's confidently-wrong implementations.
The original decision to ignore autocomplete="off" was probably the right move. But now that the autocomplete attribute has been overloaded with password manager concerns built in to web browsers these days, nobody has bothered to revisit the ordeal.