And sometimes the standard is wrong. The page telling the browser that the user isn't allowed to auto fill a form puts too much control in the hand of the page.
Maybe the standards process is broken, in which case that's something that needs fixing. I can't see why the four browser makers can't create their own browser standards.
We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
In my opinion the new spec is overly-complicated and will probably not be followed by web developers, but on the other hand a binary "on"/"off" choice was way too blunt of an instrument. I don't know how the authors of the original autocomplete spec didn't see this coming.
https://html.spec.whatwg.org/multipage/ says "4.8.4.1.1 Except where otherwise specified, the alt attribute must be specified and its value must not be empty"
Good. It's my browser. I get to turn its features on and off, not you.
And that goes double on my phone.
As a compromise, I'd accept a prompt like:
+---------------------------------------+
| This page recommends we disable |
| autocomplete. What do you think? |
|[Okay] [Fuck them; autocomplete anyway]|
+---------------------------------------+
99% of the time I agree but imagine for a second a user management system that lets an administrator edit other users profiles and a browser that decides to autocomplete the email fields in the form or name etc... Better hope auto save is not a thing...
Of course when it comes to buying things online give me my autocomplete or I hate you
imagine for a second a user management system that lets an administrator edit other users profiles
Just my $0.02, and this might be taking us out of the scope of discussion (maybe not?) but I can't think of a good business reason why an administrator needs to control whether or not the end user can use a function like autocomplete. That seems like micromanaged minutiae that will annoy my users more than help them if it's something they rely on for data entry. And if that's the case...why bother touching it in the first place?
Training/security policy that says "Be mindful of how you use this feature" to avoid any awkward NDA/HR situations? Sure, absolutely 100%.
You've completely missed the point of the comment.
Your parent was describing a system where an Administrator edits other users' data. If that Administrator is using Chrome while editing a user, then there is no way to disable autocomplete, and the browser may fill the user's form fields with the Administrator's information resulting in bad data.
I read "edit users profiles" to mean their Chrome profile, so my mistake in misreading that.
(That said though, doesn't Autocomplete in chrome only work if you select the text in the drop down and hit enter/tab? For an address field, for example if you type "123" and the box appears to select "123 Maple Street", can't you just bypass that entirely by continuing to type and not clicking on the suggestion?)
Elaborate? What is the impact of this random behavior for the-in the case of the analogy before us-an administrator? Doesn't Chrome's autocomplete, in the case of credentials know which credential belongs to what password?
If an admin goes to log into gmail on an end user machine, and enters his email address, why would the user's password pop into the password field?
The admin visits a page to edit a normal user on their website, which contains fields like email/password etc for that other user.
Chrome autocompletes the admin user's password and email in the form fields without user interaction. There was no mechanism to tell chrome not to do this if autocomplete=off is ignored, but you can set autocomplete to an arbitrary value (say =nope not =off as in spec) and it will not autocomplete.
I've seen this on real sites and had users complain about it, it is a very real issue, and unfortunately not all admin users are savvy enough to turn off autocomplete in just one instance, when they use it all the time elsewhere (even on the same website). It's nice if the website can somehow fix this by saying they really don't want autocomplete on a form to edit other users.
Personally I think the browser should give the user control, but autocomplete should not be the default if the website requests it to be off, it should be available on right click or with some easily accessible option. This should satisfy everyone and avoid situations like the one described above where the user sees arbitrary and incorrect values being filled in a form which is not related to their user and is not a login form.
Chrome copied many features from Opera (the old Opera) I'm still surprised why they decided not to copy Wand (by default the browser does not populate any fields unless you click on the wand button or use keyboard shortcut).
This works so much better than the behavior other browsers use.
What's more of a surprise is that there's a browser that has such a clumsy sounding feature as this "wand". Only power users are going to bother clicking a button just to help them fill in a form, or even know that's what the button does in the first place. That kind of manually activated feature seems to be completely against Chrome's style of minimalist UI, and for good reason, it will be one more confusing button for 90% of users to look at every day and be reminded that computers are complicated.
I wouldn't bother trying to work out some weird button, I'd just manually type my details again and again into every form and feel annoyed that the browser isn't remembering them like other browsers do.
So don't use autocomplete? I still don't understand your point.
It's not like leaving it on you are forced to use it. The client still has the choice. By turning it off you are removing choice.
If your Administrator is too stupid to stop messing up and using autocomplete where it's not appropriate, then I think the correct action here is a pink slip.
I generally agree you should try to keep users from shooting themselves in the foot, but not at the cost of hamstringing users who may want to use things differently.
Yeah, fair, but it would be a better user experience if they didn't even have the option. This directly contradicts Google's position. You're statement is basically:
Comment: User error
Closed: Won't Fix
autocomplete in chrome fills in the forms without user interaction, the user doesn't get the choice, they can only wipe the fields afterwards if they happen to notice.
We'd probably disagree on what determines a good reason. I've encountered plenty of admins that need/want god-like permissions in the app they are paying me to write.
but I can't think of a good business reason why an administrator needs to control whether or not the end user can use a function like autocomplete
I work in biotech; FDA regulated medical devices and diagnostic tests. Allowing autocomplete for forms which log you into an application which is used to sign out diagnostic reports is going to cost us in an audit.
I realize this is not a typical case, but there you have it.
People have the right to blame something for doing something wrong. If McDonald's burns my burger, I'm going to blame them, even though I can choose to not go there.
It would be a rather odd turn of events if they burned your burger without you ever visiting the place, though.
I fear that their approach is likely to just create an arms race, though. The same people who, for whatever ill-considered reasons, disabled it once will do so again. I'd rather control it as a user.
Because, honestly, I only ever see this used to keep me from having my password manager manage secure passwords, which is just obnoxious. These are usually the same sites that ban things like spaces in passwords, or cap you at 10 characters.
If you want to "turn it's features on and off", then why does the Chromium team's stance of "extensions are the standard way to enable custom behavior"[0] not apply here???
This is a classic unfortunate case of using data from the masses to drive a bad design choice because it increases "usage" along an arbitrary axis.
In the phrase you quoted, "custom" means "different from the default". It's about a choice between building customization into the browser (in the form of preferences) and relying on extensions to provide it. And it does apply here: there is no preference to honor autocomplete=off. If you want your Chrome instance to do so... find an extension.
(Though, since my quick search of the Chrome Web Store found a lot of [presumably no longer necessary] extensions to disable autocomplete=off but none to do the opposite, you might have to write it yourself. It should suffice to change "off" to an unrecognized string, as mentioned in the last comment on the issue report.)
Presumably this came about because some framework or something started including bad default attributes, and then Chrome responds by ignoring the meaning of the specification in order to "improve UX". But in the end what happens is that the specification becomes meaningless and we're back to the browser wars where you have no way of knowing how anything works except a continuous testing process to vet the veracity of the spec for any browser you are targeting, and of course this is subject to change on a whim by Google.
Will it improve the UX? Maybe... if Google is correct in its unilateral assumptions. But one thing for sure is that as a developer this costs you time, and it hurts the most if you are a well-intentioned developer who is trying to make the correct choice for your specific use case.
But, in the standard, the autocomplete attribute is a hint to the user agent, not an authoritative direction. [0]
The people who want to make it an authoritative direction ought, as you say, to take it up with the standards body.
[0]https://html.spec.whatwg.org/multipage/forms.html#autofill : "User agents sometimes have features for helping users fill forms in, for example prefilling the user's address based on earlier user input. The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature." (emphasis added)
Later that same page says : "When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user."
Yes, "should" means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
From what I can tell, while one might disagree with how the Chrome team has weighed the implications (such things always involve subjectivity), they seem to have both understood and weighed the implications before making the decision.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
They seem to have fully understood and carefully weighted the implications.
Key phrase "in particular circumstances". This is not particular circumstances, this is all inputs everywhere. The point of "SHOULD" is to allow some wiggle room for edge cases where matching the standard to the letter wouldn't make any sense, not to give browsers carte blanche to ignore SHOULDs as they please.
A mass-market web browser is a particular kind of user-agent with a particular target market and intended use; like any other specific application, it addresses a (potentially broad in an absolute sense) specific, particular set of circumstances compared to the scope of a standard.
We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
I'm really confused here, they'll disable autocomplete on almost any setting apart from "off"?
If the problem is the web designers why isn't this just pushing the problem into the future where the top stack overflow answer is autocomplete="nochrome"
or similar?
And what should I put to work cross browser? If chrome adds autocomplete when it's off and doesn't when it's set to a weird value, do other browsers do the opposite?
Yes, and every developer who understands what autocomplete="off" is supposed to do uses it with the expectation that browsers listen to that hint.
Google directly breaks developers' intentions. Chrome literally breaks implementations by ignoring this attribute that every browser respects - including previous versions of Chrome. Enabling autocomplete when it is explicitly disabled by a developer destroys UIs that provide their own replacement autocomplete functionality where it makes sense to do so.
Chrome is the worst with disrespecting developers' intentions. Even worse than this bug is the one where Chrome disbales autocomplete when specifically desired, if their broken "autodetection of login form" fails. I've had login forms, where we want the bloody autocomplete to work, not function because Chrome has their own algorithm for this shit rather than respecting the developer's wish to explicitly even enable it.
I'd like to, but I doubt they'll listen. As a compromise, I'd be happy to have browser developers allow me to ignore the more user-hostile parts of the spec.
Sometimes it's better to turn off for usability reasons, and the browser doesn't have a clue about when that's the case. For example when the page has its own autocompleter, which has more information available to it than the browser does.
A good example is the branch-switching widget on Github's repo page. Browser autocomplete is a major pain in the ass when trying to use this widget. The page can load all the branch names itself, but your dumbass browser is "helpfully" autocompleting a bunch of branch names that probably don't even exist anymore, or exist in other repos. Gee, thanks soooo much.
That's pretty much the story of the web from day one, and I'm not sure if it can actually be avoided. The incentives and desires of the content producers, browser makers, and users are all too different.
I've been trying to use the Facebook page on my phone since they've killed the FB Mobile web messenger and the amount the FB autocomplete and the Chrome autocomplete fight each other and mangle my text is spectacular.
Man, is that annoying, or login forms that are in a dynamic dialog and/or ajax-login out of band instead of a post, so that it doesn't offer a save option... I mean, I tend to use LastPass over the built-in manager, just the same, it gets annoying when sites work extra hard to subvert those things that make actually using the web easier.
Along the same lines is one of the reasons I actually like OAuth/OpenID/OpenAuth logins, etc... simply that I can avoid yet another login that I only use on one site, with yet another password, that I generate and won't remember anyway.
I could argue that it's my website and I get to decide what features I want to be usable. And if you don't like that, then go visit someone else's site.
(This is not actually my personal stance, just playing devil's advocate.)
Except that on a very real level, a website is a collection of resources along with instructions about how to assemble them. This is like getting upset at someone for putting together a Lego set "wrong."
Legos are specifically designed such that the instructions are optional. The Lego Group wants it that way. Funny you mention them, because they've been suing for trademark and copyright infringement for years.
And this is why we can't have nice things. Also playing devil's advocate, but there are days in which I think the DRM proponents actually have a point.
When all of your digital devices will be DRM enabled and controlled by means of all sorts of trusted computing techniques, when you'll no longer own or be able to tweak anything, when VLC and Firefox won't be able to play your media anymore, when the police will knock on your door because you downloaded tcpdump, remember this moment.
Curious to see whether websites will start using DRM features for this purpose.
Also, as long as changing the User-Agent header is recognized by a jury as impersonation, I can imagine that some country with retarded lawmakers [1] could require that browsers display the website the way the website owner wanted it.
[1] a.k.a. where copyright owners are allowed many things over the citizen
I could argue that it's my website and I get to decide what features I want to be usable.
Sure, and you could also argue that it's your website so you'll decide if you want to use a self-signed certificate, or lots of popups, or auto-play video with audio. That doesn't mean the browser has to listen.
Coincidentally, Google Docs does that. It disables right-click for copy/paste and prompts you in a popup to install some stupid app to re-enable this functionality.
... or you know CTRL-C/CTRL-V, cause there isn't really a good reason to prevent you pasting with a mouse.
Google Docs did this for a specific reason. Browsers restrict access to the clipboard on general user actions (like click, right click, etc). On the other hand, if you use ctrl+C or ctrl+V, the website gets access to the clipboard, because it's a JS clipboard event. So those work in Docs. Think about it - do you want any website to just read everything off your clipboard?
Docs overrides right click because there's things you'd naturally want to do in a word processor with right click (format, link, comment, etc). Because docs shows a custom menu on right click, the browser will not expose the default menu, and without the default menu, there's no JS copy/paste event.
Browser extensions have more access, and that's why a browser extension re-enables the functionality.
So it was a design choice: the Docs team decided that giving users all these other right click actions was more important than allowing the user to right click to copy/paste without an extension (since most people use the keyboard shortcuts anyway).
Good points, though, I don't agree with "most people use the keyboard shortcuts anyway".
Most not-so-tech-savvy users I know, don't know keyboard shortcuts, find them hard to remember, clumsy and slow (at least until they learn how to really use them).
I think that googles decision was valid and the best compromise they could have made. I really don't see a way how they could achieve both, without compromising the user's privacy in a manner that doesn't require a specific browser or extension.
I find that there's far more times I'd rather have autocomplete than have it actually disabled... I hate when sites force it disabled, when there's no real reason to, and as a user it's irritating.
The only time I find autofill annoying is sometimes (on my phone) lastpass will fly open at inopportune times, when entering something in a password field that's not really a password, etc.
The problem is simple: what is a login form? Browsers detect the login form from the presence of password fields and sometimes an email field. If you ever have an admin form were you can change the password of a user, you will get the autocomplete everytime, no matter what you do. You have to resort to JS. Also there are situations where you just don't want to give your users the choice (bank apps etc).
I have previously wasted so much time working around this browser behaviour.
The trick I use now is to add in a hidden (via CSS) pair on inputs earlier on the page, that do nothing. The browser fills those in, and leaves the real password admin fields empty.
I might be missing something subtle or obvious but can't you just give the inputs different names? Is it such a trauma to handle that case in the backend? e.g.
Cool, we've created several forms re-used in the same browser for different people to gather public information. We now know never to use Chrome, since its developer assumptions trump our actual design needs.
It's good to have a choice, but having to click my way through a dozen of these popups and fixed toolbars before having the content on my screen I desire is not the future I want.
Does anyone really still feel that Chrom(ium) is "your browser" anymore? It is just Google's way to exert their dominance on web standards and make paternal and self-serving decisions, all in the name of helping the "average" user.
As for extensions to allow customization, where's the extension that gives me back page actions (icons in the URL bar)? I know all the folks at Google are using shiny MBPs with billion-pixel displays, but I don't really like having 10 icons on the right of my URL bar just to show various status pages. :(
* One time password fields.
* Admin pages for dealing with users
* CC virtual terminals
* Any time that the data being collected is about a third party.
The original motivation for autocomplete=off came back when Mozilla had a small market share and Firefox and Chrome didn't exist. Some major bank websites blocked Mozilla by User-Agent. When Mozilla and Mozilla users got in contact with those banks, the banks demanded the ability to block autocomplete for their login forms. Several times afterward, when people wanted to fix autocomplete, the banks had an effective veto with "we'll block you". At the time, Mozilla didn't have nearly enough market share to say "no, that's our users' decision".
This causes many problems for app devs to work around this broken policy. StackOverflow is full of silly tricks from field naming to odd JS. Wasting time
This is the use case where the web page should not interfere, thereby enabling the user to use their password manager. You can't even log in to eBay using 1Password any more. That's ridiculous.
Perhaps what is needed is autocomplete="secure" where the browser will only autocomplete after challenging the user for a master password.
I used to solve this "security" feature by patching the Safari binary to ignore the attribute. Became too much of a hassle to chase that, but I seriously resent site developers who think they know better than I how I "should" be entering data on my machine.
Seriously - a number of the complaints on both sides of the issue in this thread point to this. Running a lab and have a problem with autocomplete remembering passwords? That's should be a site-specific setting. Have a physical issue with typing, and use assistive software? The browser should have a setting to get out of the %$&^@*% way. Run your own machine securely (by whatever standards you choose to judge that)? It shouldn't be eBay's, or Apple's, or Google's decision how you choose to type your password.
While I'm ranting, I'm seriously sick of a particular strain of arrogance mixed with refusal to take responsibility that emerges in these discussions. I recently had a discussion where a UX person confidently told me that they did, in fact, know better than I on a similar topic. OK, fine; here's a use case in which it seems that you're wrong. "Well, we can't cover every case; we have to plan for the 80% scenarios".
You know my needs better than I, but refuse to take responsibility when you're wrong? Sounds like a good time to show a bit of humility and allow the user you apparently think so little of to make a choice.
I come off the opposite end, where this browser thinks it knows the data I want to enter better than I do. It doesn't. Neither do developers. I just want to use my browser plugin and ignore them both.
For what it's worth, 1Password worked to log into eBay for me just now. Safari 9.1.1, 1Password 6.3.1.
There does seem to be a bit of an arms race with some web sites, though, where the sites manage to break 1Password (whether intentional or not, I'm not sure) and then 1Password fixes it on their end. I wouldn't be surprised if eBay was broken and then got fixed.
I've had massive problems with it for CRUD apps. Whenever you created a new user it would fill in the values from the first user you created on that system. Annoying as hell.
The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.
If the app expects the value of the field to be blank because that is what it was set to, then Chrome auto fills it, but it doesn't generate onChange events. So the app never knows the form has a value.
Not a use case, but Chrome bugs out when an input gets moved with CSS translate() and the autocomplete is open. The autocomplete stays in place unchanged while the input zooms off.
Even if that wasn't the case, a well design form element that animates (transition in a game) looks very different to a deafault-autocomplete I can't turn off.
I fully support the decision by Chrome. I hate when forms try and force it off and get me to type the same thing over and over. It's an abused attribute.
I see this as a good thing. Far better to streamline password management than to make it bumpy, encouraging users to use memorable passwords, which most likely will also be painfully weak.
It would make more sense, if you were familiar with the Unix command line. Pretty much whenever something tells you "Permission denied", you just retype the same command with "sudo" before it and then it does what you want.
And yeah, that definitely happens often enough to be a running joke among Unix users.
That would be a negative user experience, given the prevalence of legacy forms on the web. Example: "Why does this autocomplete feature fail most of the time?"
I'm going to side with the Chrome team on this one. There's very few occasions when autocomplete being disabled makes sense, the vast majority are just developers dumping it in there because they want to make doubly-sure the user actually entered a field by hand (e.g. email addresses) and often for vaporous reasons like "Improve Data Quality," "Stop Spammers/Bots," and "Make sure the user enters the right data in the right box."
Ultimately if you want to assure data quality then use data or format validation, or verification (e.g. send an email with link). If you want to stop bots/spammers use captcha.
We did go through a period where people were "misusing" standard input boxes for other things and autocomplete would ruin that extra usage. But hopefully we've moved beyond turning an input box into a richtextbox using a complex array of hacks, and can now instead use things like Canvas.
PS - Hopefully they disable "smooth scroll" scripts next. So tired of having my scrolling ruined by "helpful" sites.
There's very few occasions when autocomplete being disabled makes sense
True, perhaps. The point is that's not for Google to decide. In their example with CRM system, it's very possible that the developer did think about it, and decided that autocompletion would "help" the user enter wrong data.
Now Chrome forces you to be non-compliant to work-around to their "custom feature".
Chrome is increasingly encouraging developer behaviour that's reminiscent of Microsoft and Internet Explorer 6.
So if autocomplete breaks functionality then there's nothing the user can do if the developer assumed autocomplete='off' would continue to work.
Developers should not expect that things specced as hints will be treated as authoritative direction and should not make software that breaks if that unreasonable expectation doesn't hold.
I'll give one. A text input for a chat you're having with someone. It's very very offputting and irritating to have the browser constantly cluttering the UI with suggestions about what you might want to type in that chat box before you press enter.
Chat input is typically single-line, submit-on-enter. Messaging apps seem to be transitioning to optional multiline but the default action for enter still seems to be submit so it's perfectly reasonable to use <input> for chat input.
Well, inline chat, like IRC is generally a single-line input... though I suppose you could use a textarea rows="1" and strip \n on paste, etc, that wouldn't be too bad as you're likely listening for \n to post the message anyway.
Either way, not using a typical name/id for the text input would probably work better in terms of not getting suggestions...
That would indeed be the norm for forums. But not for chat. Real time chat is typically more usually a single line entry. Having auto-complete on that is irritating and utterly spoils the UI.
I know of one from a previous project. We had a prompt that said "enter your home address" with JavaScript autocomplete using google location APIs. Unfortunately chrome would try to auto fill this box with a city name (not even the full address) and this auto fill prompt sat on top of the JS drop down.
Well, the web technology is a pile of sh.t and in this case with the textarea you don't put your hands as deep in to is as you'd with the text input. That's how I interact with the web technology.
In our user management portal, whenever tech support opens the Create New User or Reset User Password page Chrome helpfully fills their administrative password into the user's password field.
So in your user management portal, you assign new users or replace your lost passwords with passwords you set, thus you know? Oh my days! Generate it randomly and mail the user, or better, mail them a link to reset/create password page. Otherwise, just make it a plain input field, because if you know it, it's not hidden anyways.
The irony is when I have to hand-enter my email address, especially on my phone, I'm far more likely to mistype it and make a mistake... And on the receiving side, I'm sick of seeing emails for someone else.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
Reminds me of the good old days of making things work with IE6.
Again, thanks to everyone for your comments. We look forward to continuing the conversation.
Sure you do. Then why is commenting closed?[1]
[1]: See the "Restricted- Only users with EditIssue permission may comment." box on the left pane.
All this said, we're still learning. So we would like to better understand your use cases for setting autocomplete=off. To have that conversation in a more focused manner, I've created a new bug: crbug.com/587466. We're going to try and keep that conversation focused and productive, so we want to avoid "+1s" and the like. I'll be closing this bug in the meantime.
'The semantic meaning' hack is bad for readability. You don't actually mean 'new-user-street-address' you mean 'do not autofill this input chrome.' The next developer in will assume the semantic meaning accomplishes something, and decorating your markup with things that may or may not do nothing seems is bad practice.
Some years ago we had trouble with autocomplete. Browsers would fill in credit card details and customers would call us where we've got their credit card details from. Or they we're completed into a different website and people called us why we gave the other website the CC details.
I actually find this particularly annoying working for a service aimed at elementary schools.
Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.
Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.
We have a similar issue in the quality management space.
Multiple quality folks on a shop floor accessing a QMS from the same machine. If an IT admin forgets to disable password saving, compliance rules could be broken if one quality member has the ability to electronically sign a document using someone else's saved password.
Why should app developers have the power by default? It sounds to me like you're arguing for that just because that happens to be what you have trouble with. But I'm sure we can find plenty of other people where having the default be the other way would work better.
Your actual problem is that your users can't change even the most basic settings, and you're not in a position to change it for them. I'm sure autocomplete isn't the first nor the last symptom you'll have due to this problem. Good defaults are important, but good defaults are about more than what works for shared desktops in schools with clueless IT people.
What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around.
If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?
After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.
Assumes a competent, dedicated local admin is on staff. This is not the case at about 75% of the SMBs I've come into contact with over the past two years
Modern operating systems have a guest mode which doesn't preserve state across sessions - if they cannot manage something this easy, everyone should be using a guest login.
Websites will always have the ability to disable auto-complete though. Just now it will be though a series of ever-increasingly insane hacks found on StackOverflow (culminating in a custom JavaScript textfield with broken accessibility/internationalization)
We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2]
In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
If you would read what they actually wrote you would notice that - as usual - the headline does not even remotely catch the complexity of the problem.
Not all school admins are smart enough to disable password saving
So how would allowing a small percentage of web apps to disable autocomplete resolve this? It only makes it slightly less painful for the websites where autocomplete is disabled - everywhere else you have the same problem. You're asking the wrong people to solve this for you here.
Horrible. There are cases when autocomplete="off" is necessary to improve user experience. It's sad that such policies are defined by people not familiar with web development enough to know such cases.
Also, some forms will become inconsistent when autocomplete="off" is ignored (radio button filled by autocomplete instead of the value specified by developer, but the related text input field is disabled as specified by developer).
Moreover, it's a standard. Everyone was complaining about Microsoft when it introduced non-standard HTML and Javascript semantics. Now Google does that.
It'll be amusing if this creates an arms race where Google ignores more and more autocomplete values, until someone just makes an Apache/nginx extension which just gives them a random value.
Chrome 60 will now calculate the entropy of the value, and if it appears to contain more entropy than typical strings it will ignore the value and whack the programmer on the head.
Turning it off in other browsers? What do other browsers do when they don't understand the setting? If any of the others say "well it doesn't say off, so let's leave autocomplete on" then you're a bit screwed.
Considering how the entirety of web development works, you could probably just include both values and then the browsers would figure out themselves which one they want to listen to.
i love autocomplete and i hate when the page tries to turn it off for no logical reason. I have an extension installed that forces autocomplete on for everything.
In some cases because their legacy systems can't support long passwords. I know my previous bank was restricted to 6 digits (maybe even just 4). Their solution was to add in those annoying security questions like "What was your first dog's name". Sigh.
I use Diceware for those things, in case I have to use them over the phone. "My dog's name is effervescent mandible egg voldemort; my mother's maiden name is regent utterly busted harpy"
I called Schwab once because a LastPass misstep locked me out of my account. The CSR told me it was great that I was using a password manager and that she wished more people used them.
I guess it keeps her employed ;) But on a more serious note, banks are not as stupid and anti-technology as the average HN reader wants to believe. Their programmers are no doubt here too.
(Now why Schwab limits me to an 8 character password... I don't even want to know. But I do have a _good_ 8 character password ;)
We don't just ignore the autocomplete attribute, however. In the WHATWG standard, we defined a series of new autocomplete values that developers can use to better inform the browser about what a particular field is, and we encourage developers to use those types. [2] https://html.spec.whatwg.org/multipage/forms.html#autofill
Okay, aside from what you think about being unable to just turn off autocomplete, those semantic tabs actually sound super useful, and i hadn't known about them.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address".
Um, "new-user-street-address" does not appear in the list of recognized values from the WHATWG spec that was linked to above.
How do we find the list of values that Chrome actually recognizes and what they mean?
Am I missing it somewhere else? How does Chrome expect devs to use something completely un-doc'd?
In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
They're saying that they don't autofill when they see autocomplete values which Chrome doesn't recognize, so if you don't want autofill, they suggest you just put in a description of what this field is, which won't be recognized. The functionality is the same as if you put in autocomplete="foobarbazquux", but it's better-described.
Ah, thanks, I didn't do it on purpose, I was just confused. Because:
our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. If we encounter an autocomplete attribute that we don't recognize, we won't try and fill it.
How is a value not allowed by the spec "valid" as they say? They're encouraging you to violate the spec to trigger chrome-specific behavior (can't really say what other browsers will do when spec is violated, can you?), really? Or does the spec say you're allowed to make up new values too? i don't _think_ so, but maybe I missed that part (not being sarcastic).
It was my understanding that currently Chrome doesn't support any special behaviour for custom values of the autocomplete attribute. I think they just want to get people used to this and probably start capturing data (via web crawls) of what values people actually use to decide what to implement in the future.
It's tough to say that Chrome made the right call, as I enjoy being able to (in theory) rely on browsers aiming to be standard compliant. The standard is there for a reason, no?
I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin
The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo.
You can play with this yourself: http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script)
My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.
I think it is necessary for some fields to have autocomplete="off" for PCI compliance (login/password field if I remember correctly).
So this creates the interesting situation where I should set autocomplete to something else so that chrome doesn't complete it, but that would result in a failed compliance check.
Yes. PCI is a silly substitute for actual security. But the alternative is that many banks and their partners will run with no security because bank executives as a class are firmly opposed to sharing authority with competent IT security people.
I have some pages with passwords but not usernames, and chrome keeps trying to treat it as a login, picking an arbitrary nearby field as username, and ignores all markup suggesting otherwise. It's on my todo list to figure out something that bypasses its stupidity, like setting it to a normal field with a weird font, as it's not necessary to prevent copying out of the field.
This is one of the few cases where I'm actually in favor of Chrome's rogue behavior, though I think they're probably doing it for the wrong reasons. I've been annoyed one too many times by webpages that refuse to allow me to autofill login credentials from my browser, to the point where I had to keep a js bookmarklet to strip that attribute from every element on the page. I always hated that it took such a hacky solution to do something which is so simple, and resented sites that attempted to take that ability away from me.
So to me, any change which puts control back in the hands of the user is a good one. I suspect though that the motivation is mostly to "increase engagement" rather than to empower the user.
I've noticed that a great deal of secure websites will disable autofill in their username and password fields on purpose. For ages I've had a Chrome extension installed that disabled autofill=off to get around exactly that, and I believe I'll leave it enabled. I know better than to trust plain password auth anyway, and mostly use the feature to remember one-time passwords to things like forum sites that have the ridiculous policy of hiding plain URLs to non-registered users. (I will never understand what a forum gains by having a large number of users in their database who registered once to download that one attachment, then never came back again.)
Regardless of the intent, I think when you try to make decisions on behalf of your users, you're doing them a disservice. I mean, really, the security risk of autofill on password fields is that the user's passwords are now saved on their computer? I think users who need to utilize this feature and have it denied them will just end up typing the password into a word document named "Passwords.docx," and that's a heck of a lot less secure than Chrome's encrypted password store. Not that Chrome's implementation couldn't be better, but still.
Why use a Word document? I put all my security passwords—especially the ones that won't autoflll or that make me change them often—into a Google Docs spreadsheet online. That way I can get to my passwords from anywhere.
Trusting users over developers will lead to less security overall. In this case it will make providing intranet access to employee owned devices a little less secure or less user friendly (by blocking chrome)
Here's a huge reason why this is bad. Our company let's you set a "global password" to lock your site. Chrome was auto-filling the password site silently, and exposing people's personal passwords to their whole team when they saved. I understand wanting control, but... Sometimes this is horrible behavior.
Why isn't that a bug in your application? Unless you're building a password manager, passwords should never be shown to someone else. If you need the ability to let multiple people do things, they should still perform the action using their private credentials so you'd have accurate records for who initiated the action.
As an example, if you have an address input field in your CRM tool that you don't want Chrome to Autofill, you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead.
That's clearly a suboptimal practice by Google's web team. Which doesn't make Google's Chrome team wrong, but maybe the latter should have a word with the former.
Sure, there is. You could do a meaningful semantic autocomplete tag that isn't one of the recognized ones, rather than a variant of "no, really, don't autocomplete this". (Actually, "body" is probably not a bad practice, but the other one was.)
So many ugly hacks are needed as a consequence of this.
I know what I want my app to do better than you Chrome. Please don't purposely break the Internet.
When I try to do user management. I can't call the fields `username` or `password` because Chrome will attempt to autofill it with the saved user/pass from the login. So annoying. :(
Also, it doesn't trigger onChange events when it gets autofilled. :(
This breaks Angular because the field's value is different from what Angular thinks the field's value is.
It feels like the solution here is to have a serious-business flag for chrome like phabricator does. Is the browser working for me or is it just helping me work for someone else? That seems to be the real intent problem here. I feel for all the CRM types and data entry people that are going to struggle with this. The user may decide that they don't want autocomplete for a page but they may not be sophisticated enough to turn it off in a meaningful way, or for a particular site.
I still think it's really troublesome that it invents a user-side data store of potentially sensitive data that they really had no say in.
Good. It's taken far too long for user agents and web standard to remember that the intent of a user agent is to be an agent for a user, not something that an external server can dictate with pixel perfect precision.
Where "phone" is the honeypot field. Not shown in-browser, so usually only a bot will fill out the honeypot field, sending a strong signal that the form is an automated/spam request.
Of course, autofill messes this up. So the more correct implementation is to turn it off:
The way I understand it, it's not that autocomplete can't be turned off, it's that "off" no longer turns it off. You can still turn it off in plenty of other ways.
Another possibility would be to add two fields dynamically via JS at load, the first populated at load with a timestamp when the form was loaded... then add onkeyup/onfocus/onclick events for the other form fields, and when triggered populate the second field with the current timestamp.
From there, you can compare the numbers, offset from the current time, and do other checks. I mean, you might want to allow for up to an hour of drift, but most people won't sit on a page for an hour then hit submit.
Though it would be circumvented easy enough, if it's custom, would worry less about it.
The one that I wouldn't mind changing is when the site somehow blocks pasting a password into the field. Yes, I'm not typing it because I use a password manager thank you very much!
The rationale for ignoring autocomplete=off makes sense to me. What I don't understand at all is the suggested "workaround" for disabling autocomplete:
In cases where you really want to disable autofill, our suggestion at this point is to utilize the autocomplete attribute to give valid, semantic meaning to your fields. [...] As an example, if you have an address input field [...], you can give it semantic meaning that makes sense relative to what you're asking for: e.g. autocomplete="new-user-street-address". If Chrome encounters that, it won't try and autofill the field.
So essentially they encourage authors to make up random, nonstandard values for the attribute that may or may not do what the author is hoping for.
I don't see what this will archieve except making the autocomplete attribute a pain to use in practice.
(Which might be what the Chrome team intends, but even then, a more straight-forward and more honest way would be deprecation.)
they encourage authors to make up random, nonstandard values for the attribute
No, they are encouraging you to give more meaning to your fields. For the example given of a CRM app, using customer_email_address as the input field makes much more sense than using a standard value for email address, as the two fields are asking for different things: The latter always wants your email address, whereas the former wants the relevant email address for the record you're viewing/editing.
But there is no guarantee all sites will use the same values or even give the values the same meaning: One might write "customer_email_address", another "e-mail-address-of-customer". A third one has separate input fields for the parts before and after the "@" and uses "email-address-name" and "email-address-host" respectively...
So in the end, if everyone followed the advice and used "semantic" values, this would likely lead to the same problems that HTML already had with semantic class names, rel values and meta tags. The discussions about them fill mailing list archives. I don't see why all this should be repeated, even more so as the problem of semantically annotating your elements is already solved.
But in this case it's even weirder as that was presented as a way to tell Chrome "please don't autocomplete". So if that's the real motivation, then sites are likely to just put some variant of "really-really-off", or just random strings in it without any regard to "semantics".
Would you ever want autocomplete on, say, a field where you're inputting a 2FA response? Probably not, since any suggestions would be useless.
I find the workaround of "just put some other random bullshit for the value" hilarious. And once developers start over-abusing that as well (they will), then what's the plan?
One of the commenters on the linked bug to discuss valid use cases for autocomplete=off hits a wonderful nail on the head:
Actually there is a famous site called http://www.google.com they use autocomplete="off" for their search form since every time you visit the site you want to search something completly different.
I wish I had been able to find this a few weeks ago. Was working on a modified login feature where the autocomplete behavior was actually a hinderance to a UX improvement we were working on.
Not making a comment either way on whether they should be doing this, but ... I think we all know what's going to come next :(
//add random number to stop Chrome from disabling autocomplete
//--number is stripped off in form processing routine
print "Address: <input type='text' name='address--" . rand() . "'>";
How long before somebody uses that to guess your physical address by creating a page with input field named 'address' and so on just to read their values with JS?
The problem is you can't read autofill values with JS. This leads to a horrible experience for users when you have say an Angular form that gets autofilled and they click submit and it tells them the form is missing data.
For the love of FSM, why is it that browser vendors are always so f%!#ng arrogant?? It's not just Chrome, we've seen this attitude from Firefox devs before as well: "fuck you, we know more about what you meant than you do".
I really wish somebody would fork either Chromium or Firefox and commit to delivering a browser that just fully, completely and accurately implements the various specifications, instead of trying to "improve" them like this.
The weird thing is, `autocomplete=off` _does_ seem to have the intended effect on my Chrome. OSX 50.0.2661.102. Huh? Was this change made in a later version I haven't gotten yet?
I ranted about this on my blog whilst drunk, and then went off in a tangent, you can find it at jameshalsall.co.uk, 2nd post.
This really makes me uncomfortable, standards are there for a reason, you don't just ignore them because you don't agree with them.
And sometimes the standard is wrong. The page telling the browser that the user isn't allowed to auto fill a form puts too much control in the hand of the page.
Sure. Fix the standard, don't just make shit up.
Maybe the standards process is broken, in which case that's something that needs fixing. I can't see why the four browser makers can't create their own browser standards.
You often need in-the-field experience with a proposed change before it's considered.
Standards are just made-up shit. Most of them are formalized descriptions of what people were already doing before the standard existed.
Correct me if I'm wrong, but no browsers have formally committed to adhering to the standards.
Don't know about that, but they certainly like to brag about the size of their standards compliance penis.
That sounds like what they're doing.
In my opinion the new spec is overly-complicated and will probably not be followed by web developers, but on the other hand a binary "on"/"off" choice was way too blunt of an instrument. I don't know how the authors of the original autocomplete spec didn't see this coming.
The standard is that autocomplete attribute can be used to hint to the user-agent how to apply any autocomplete functionality it has.
The standard is not that the UA must provide autocompletion when it is "on", or must not do so when it is "off".
So, I don't see any problem with the standard and Chrome's behavior.
Actually, the standard says that "on" is a MAY, but "off" is a SHOULD.
Yes, and neither is a MUST.
SHOULD is not SHALL.
The standard is only a hint to the user agent, not a MUST.
Except, it is a SHOULD.
People always ignore the bits of the standards they don't agree with; taking an entirely dickish and non-random example e.g.
<img src="http://secure.gravatar.com/avatar/df0e70f6e810442b86d701afcb...
https://html.spec.whatwg.org/multipage/ says "4.8.4.1.1 Except where otherwise specified, the alt attribute must be specified and its value must not be empty"
Or having 4 <section> but only 3 </section>.
Good. It's my browser. I get to turn its features on and off, not you.
And that goes double on my phone.
As a compromise, I'd accept a prompt like:
99% of the time I agree but imagine for a second a user management system that lets an administrator edit other users profiles and a browser that decides to autocomplete the email fields in the form or name etc... Better hope auto save is not a thing...
Of course when it comes to buying things online give me my autocomplete or I hate you
- love your recommendation for a browser prompt!
imagine for a second a user management system that lets an administrator edit other users profiles
Just my $0.02, and this might be taking us out of the scope of discussion (maybe not?) but I can't think of a good business reason why an administrator needs to control whether or not the end user can use a function like autocomplete. That seems like micromanaged minutiae that will annoy my users more than help them if it's something they rely on for data entry. And if that's the case...why bother touching it in the first place?
Training/security policy that says "Be mindful of how you use this feature" to avoid any awkward NDA/HR situations? Sure, absolutely 100%.
Curious what others think on this?
You've completely missed the point of the comment.
Your parent was describing a system where an Administrator edits other users' data. If that Administrator is using Chrome while editing a user, then there is no way to disable autocomplete, and the browser may fill the user's form fields with the Administrator's information resulting in bad data.
I read "edit users profiles" to mean their Chrome profile, so my mistake in misreading that.
(That said though, doesn't Autocomplete in chrome only work if you select the text in the drop down and hit enter/tab? For an address field, for example if you type "123" and the box appears to select "123 Maple Street", can't you just bypass that entirely by continuing to type and not clicking on the suggestion?)
If you allow it to remember your login credentials it will autofill any input that it thinks is a login / password.
That leads to some random behaviour.
That leads to some random behaviour.
Elaborate? What is the impact of this random behavior for the-in the case of the analogy before us-an administrator? Doesn't Chrome's autocomplete, in the case of credentials know which credential belongs to what password?
If an admin goes to log into gmail on an end user machine, and enters his email address, why would the user's password pop into the password field?
I'm afraid I don't understand your counterpoint.
The admin visits a page to edit a normal user on their website, which contains fields like email/password etc for that other user.
Chrome autocompletes the admin user's password and email in the form fields without user interaction. There was no mechanism to tell chrome not to do this if autocomplete=off is ignored, but you can set autocomplete to an arbitrary value (say =nope not =off as in spec) and it will not autocomplete.
I've seen this on real sites and had users complain about it, it is a very real issue, and unfortunately not all admin users are savvy enough to turn off autocomplete in just one instance, when they use it all the time elsewhere (even on the same website). It's nice if the website can somehow fix this by saying they really don't want autocomplete on a form to edit other users.
Personally I think the browser should give the user control, but autocomplete should not be the default if the website requests it to be off, it should be available on right click or with some easily accessible option. This should satisfy everyone and avoid situations like the one described above where the user sees arbitrary and incorrect values being filled in a form which is not related to their user and is not a login form.
Chrome copied many features from Opera (the old Opera) I'm still surprised why they decided not to copy Wand (by default the browser does not populate any fields unless you click on the wand button or use keyboard shortcut).
This works so much better than the behavior other browsers use.
What's more of a surprise is that there's a browser that has such a clumsy sounding feature as this "wand". Only power users are going to bother clicking a button just to help them fill in a form, or even know that's what the button does in the first place. That kind of manually activated feature seems to be completely against Chrome's style of minimalist UI, and for good reason, it will be one more confusing button for 90% of users to look at every day and be reminded that computers are complicated.
I wouldn't bother trying to work out some weird button, I'd just manually type my details again and again into every form and feel annoyed that the browser isn't remembering them like other browsers do.
Mostly on sites that both have traditional login forms and use forms where other fields are mis-identified as password fields.
So don't use autocomplete? I still don't understand your point.
It's not like leaving it on you are forced to use it. The client still has the choice. By turning it off you are removing choice.
If your Administrator is too stupid to stop messing up and using autocomplete where it's not appropriate, then I think the correct action here is a pink slip.
I generally agree you should try to keep users from shooting themselves in the foot, but not at the cost of hamstringing users who may want to use things differently.
Yeah, fair, but it would be a better user experience if they didn't even have the option. This directly contradicts Google's position. You're statement is basically: Comment: User error Closed: Won't Fix
autocomplete in chrome fills in the forms without user interaction, the user doesn't get the choice, they can only wipe the fields afterwards if they happen to notice.
We'd probably disagree on what determines a good reason. I've encountered plenty of admins that need/want god-like permissions in the app they are paying me to write.
I work in biotech; FDA regulated medical devices and diagnostic tests. Allowing autocomplete for forms which log you into an application which is used to sign out diagnostic reports is going to cost us in an audit.
I realize this is not a typical case, but there you have it.
It's Google's browser. This is your mistake for using Google's browser if you don't agree with what Google wants their browser to do.
Exactly. I have no idea why people blamed IE for not following standards. It was totally all of its users' fault for using it.
People have the right to blame something for doing something wrong. If McDonald's burns my burger, I'm going to blame them, even though I can choose to not go there.
It would be a rather odd turn of events if they burned your burger without you ever visiting the place, though.
I fear that their approach is likely to just create an arms race, though. The same people who, for whatever ill-considered reasons, disabled it once will do so again. I'd rather control it as a user.
Because, honestly, I only ever see this used to keep me from having my password manager manage secure passwords, which is just obnoxious. These are usually the same sites that ban things like spaces in passwords, or cap you at 10 characters.
Uhm.... your reply makes no sense - what he says is in support of the Chrome decision.
If you want to "turn it's features on and off", then why does the Chromium team's stance of "extensions are the standard way to enable custom behavior"[0] not apply here???
This is a classic unfortunate case of using data from the masses to drive a bad design choice because it increases "usage" along an arbitrary axis.
[0] https://news.ycombinator.com/item?id=11729287
In the phrase you quoted, "custom" means "different from the default". It's about a choice between building customization into the browser (in the form of preferences) and relying on extensions to provide it. And it does apply here: there is no preference to honor autocomplete=off. If you want your Chrome instance to do so... find an extension.
(Though, since my quick search of the Chrome Web Store found a lot of [presumably no longer necessary] extensions to disable autocomplete=off but none to do the opposite, you might have to write it yourself. It should suffice to change "off" to an unrecognized string, as mentioned in the last comment on the issue report.)
Given the autocomplete detail tokens[1] - my first thought was
Or something similar.
[1] https://html.spec.whatwg.org/multipage/forms.html#autofill-d...
The Chromium team's stance of "extensions [...]" is better understood as: "get the fuck off my lawn."
I agree.
And nothing prevents us from dropping, on ~/.js
Is ~/.js something I should know about? Somewhere to add snippets of Javascript which are run unconditionally by Chrome on any page load?
I'm just praying it's not some new lodash like library I have to learn.
https://github.com/defunkt/dotjs
The Dotjs extension is no longer maintained, just for those looking at this and wondering if it's worthwhile.
Take it up with the standards body then.
Presumably this came about because some framework or something started including bad default attributes, and then Chrome responds by ignoring the meaning of the specification in order to "improve UX". But in the end what happens is that the specification becomes meaningless and we're back to the browser wars where you have no way of knowing how anything works except a continuous testing process to vet the veracity of the spec for any browser you are targeting, and of course this is subject to change on a whim by Google.
Will it improve the UX? Maybe... if Google is correct in its unilateral assumptions. But one thing for sure is that as a developer this costs you time, and it hurts the most if you are a well-intentioned developer who is trying to make the correct choice for your specific use case.
But, in the standard, the autocomplete attribute is a hint to the user agent, not an authoritative direction. [0]
The people who want to make it an authoritative direction ought, as you say, to take it up with the standards body.
[0] https://html.spec.whatwg.org/multipage/forms.html#autofill : "User agents sometimes have features for helping users fill forms in, for example prefilling the user's address based on earlier user input. The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature." (emphasis added)
Later that same page says : "When an element's autofill field name is "off", the user agent should not remember the control's data, and should not offer past values to the user."
(The word "should" has its own meaning in RFCs generally http://www.ietf.org/rfc/rfc2119.txt and in whatwg specifically https://wiki.whatwg.org/wiki/Specs/howto#Content)
Yes, "should" means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
From what I can tell, while one might disagree with how the Chrome team has weighed the implications (such things always involve subjectivity), they seem to have both understood and weighed the implications before making the decision.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
They seem to have fully understood and carefully weighted the implications.
Key phrase "in particular circumstances". This is not particular circumstances, this is all inputs everywhere. The point of "SHOULD" is to allow some wiggle room for edge cases where matching the standard to the letter wouldn't make any sense, not to give browsers carte blanche to ignore SHOULDs as they please.
A mass-market web browser is a particular kind of user-agent with a particular target market and intended use; like any other specific application, it addresses a (potentially broad in an absolute sense) specific, particular set of circumstances compared to the scope of a standard.
It's not all circumstances, quoted from TFA:
I'm really confused here, they'll disable autocomplete on almost any setting apart from "off"?
If the problem is the web designers why isn't this just pushing the problem into the future where the top stack overflow answer is autocomplete="nochrome" or similar?
And what should I put to work cross browser? If chrome adds autocomplete when it's off and doesn't when it's set to a weird value, do other browsers do the opposite?
Yes, and every developer who understands what autocomplete="off" is supposed to do uses it with the expectation that browsers listen to that hint.
Google directly breaks developers' intentions. Chrome literally breaks implementations by ignoring this attribute that every browser respects - including previous versions of Chrome. Enabling autocomplete when it is explicitly disabled by a developer destroys UIs that provide their own replacement autocomplete functionality where it makes sense to do so.
Chrome is the worst with disrespecting developers' intentions. Even worse than this bug is the one where Chrome disbales autocomplete when specifically desired, if their broken "autodetection of login form" fails. I've had login forms, where we want the bloody autocomplete to work, not function because Chrome has their own algorithm for this shit rather than respecting the developer's wish to explicitly even enable it.
I'd like to, but I doubt they'll listen. As a compromise, I'd be happy to have browser developers allow me to ignore the more user-hostile parts of the spec.
Sometimes it's better to turn off for usability reasons, and the browser doesn't have a clue about when that's the case. For example when the page has its own autocompleter, which has more information available to it than the browser does.
A good example is the branch-switching widget on Github's repo page. Browser autocomplete is a major pain in the ass when trying to use this widget. The page can load all the branch names itself, but your dumbass browser is "helpfully" autocompleting a bunch of branch names that probably don't even exist anymore, or exist in other repos. Gee, thanks soooo much.
" For example when the page has its own autocompleter"
Wouldn't that just override whatever values Chrome throws in there anyway? (If you're using JS.)
No.
There are ways to resolve those situations properly as explained in the link being discussed.
So you defeat the autocomplete by messing with attributes in a slightly different way, and we've just gone in a circle. Great job everybody.
That's pretty much the story of the web from day one, and I'm not sure if it can actually be avoided. The incentives and desires of the content producers, browser makers, and users are all too different.
I've been trying to use the Facebook page on my phone since they've killed the FB Mobile web messenger and the amount the FB autocomplete and the Chrome autocomplete fight each other and mangle my text is spectacular.
I'd much rather have things like that broken then have to futz around with someones stupid login form that disabled password pasting and autocomplete.
Man, is that annoying, or login forms that are in a dynamic dialog and/or ajax-login out of band instead of a post, so that it doesn't offer a save option... I mean, I tend to use LastPass over the built-in manager, just the same, it gets annoying when sites work extra hard to subvert those things that make actually using the web easier.
Along the same lines is one of the reasons I actually like OAuth/OpenID/OpenAuth logins, etc... simply that I can avoid yet another login that I only use on one site, with yet another password, that I generate and won't remember anyway.
I could argue that it's my website and I get to decide what features I want to be usable. And if you don't like that, then go visit someone else's site.
(This is not actually my personal stance, just playing devil's advocate.)
Except that on a very real level, a website is a collection of resources along with instructions about how to assemble them. This is like getting upset at someone for putting together a Lego set "wrong."
Legos are specifically designed such that the instructions are optional. The Lego Group wants it that way. Funny you mention them, because they've been suing for trademark and copyright infringement for years.
And this is why we can't have nice things. Also playing devil's advocate, but there are days in which I think the DRM proponents actually have a point.
When all of your digital devices will be DRM enabled and controlled by means of all sorts of trusted computing techniques, when you'll no longer own or be able to tweak anything, when VLC and Firefox won't be able to play your media anymore, when the police will knock on your door because you downloaded tcpdump, remember this moment.
Curious to see whether websites will start using DRM features for this purpose.
Also, as long as changing the User-Agent header is recognized by a jury as impersonation, I can imagine that some country with retarded lawmakers [1] could require that browsers display the website the way the website owner wanted it.
[1] a.k.a. where copyright owners are allowed many things over the citizen
You could argue that, but the user who owns the web browser has all the power in this situation. It's an arms race the website operator cannot win.
Sure, and you could also argue that it's your website so you'll decide if you want to use a self-signed certificate, or lots of popups, or auto-play video with audio. That doesn't mean the browser has to listen.
I agree. I always hated sites that disable Paste, disable right-click or whatever.
Coincidentally, Google Docs does that. It disables right-click for copy/paste and prompts you in a popup to install some stupid app to re-enable this functionality.
... or you know CTRL-C/CTRL-V, cause there isn't really a good reason to prevent you pasting with a mouse.
I really don't get that
Google Docs did this for a specific reason. Browsers restrict access to the clipboard on general user actions (like click, right click, etc). On the other hand, if you use ctrl+C or ctrl+V, the website gets access to the clipboard, because it's a JS clipboard event. So those work in Docs. Think about it - do you want any website to just read everything off your clipboard?
Docs overrides right click because there's things you'd naturally want to do in a word processor with right click (format, link, comment, etc). Because docs shows a custom menu on right click, the browser will not expose the default menu, and without the default menu, there's no JS copy/paste event.
Browser extensions have more access, and that's why a browser extension re-enables the functionality.
So it was a design choice: the Docs team decided that giving users all these other right click actions was more important than allowing the user to right click to copy/paste without an extension (since most people use the keyboard shortcuts anyway).
Good points, though, I don't agree with "most people use the keyboard shortcuts anyway".
Most not-so-tech-savvy users I know, don't know keyboard shortcuts, find them hard to remember, clumsy and slow (at least until they learn how to really use them).
I think that googles decision was valid and the best compromise they could have made. I really don't see a way how they could achieve both, without compromising the user's privacy in a manner that doesn't require a specific browser or extension.
Most people, actually, use the toolbars. Neither right-click nor keyboard shortcuts come close to toolbar usage amongst "normals"
The toolbar works just like that. It tells you to press command + V (or control + V on Windows) as well.
I've had this bookmarklet for years on my toolbar, fixes all kinds of hijacks..
javascript:void(document.onmousedown=null);void(document.onclick=null);void(document.oncontextmenu=null)
Counter argument: Chrome doesn't ask you, and they don't provide any way for you to respect the standard behaviour.
If it breaks websites you use then your only option is to completely disable autocomplete.
I find that there's far more times I'd rather have autocomplete than have it actually disabled... I hate when sites force it disabled, when there's no real reason to, and as a user it's irritating.
The only time I find autofill annoying is sometimes (on my phone) lastpass will fly open at inopportune times, when entering something in a password field that's not really a password, etc.
The problem is simple: what is a login form? Browsers detect the login form from the presence of password fields and sometimes an email field. If you ever have an admin form were you can change the password of a user, you will get the autocomplete everytime, no matter what you do. You have to resort to JS. Also there are situations where you just don't want to give your users the choice (bank apps etc).
This!
I have previously wasted so much time working around this browser behaviour.
The trick I use now is to add in a hidden (via CSS) pair on inputs earlier on the page, that do nothing. The browser fills those in, and leaves the real password admin fields empty.
I might be missing something subtle or obvious but can't you just give the inputs different names? Is it such a trauma to handle that case in the backend? e.g.
<input name='admin-user'><input name='admin-pass'>?
(Now if Chrome is auto{fill,complet}ing those with usernames + passwords, that's definitely a disastrous bug.)
Now if Chrome is auto{fill,complet}ing those with usernames + passwords, that's definitely a disastrous bug
You say "bug", they say "works as designed".
Interesting trick.
Cool, we've created several forms re-used in the same browser for different people to gather public information. We now know never to use Chrome, since its developer assumptions trump our actual design needs.
Since you have direct control of the browser, the simplest answer would be to go to settings and turn off autocomplete entirely.
Autocomplete in chrome is one of its worst features. From a user and developer perspective.
Flash. Cookies. Location. Autocomplete?
It's good to have a choice, but having to click my way through a dozen of these popups and fixed toolbars before having the content on my screen I desire is not the future I want.
Does anyone really still feel that Chrom(ium) is "your browser" anymore? It is just Google's way to exert their dominance on web standards and make paternal and self-serving decisions, all in the name of helping the "average" user.
As for extensions to allow customization, where's the extension that gives me back page actions (icons in the URL bar)? I know all the folks at Google are using shiny MBPs with billion-pixel displays, but I don't really like having 10 icons on the right of my URL bar just to show various status pages. :(
You can drag the right edge of your URL bar left and right to show or hide those icons.
Is there ever a reason to honor that setting?
A valid reason is a search field, on a shared system where you do not want it to autofill with past searches.
If the site has its own autocomplete?
The original motivation for autocomplete=off came back when Mozilla had a small market share and Firefox and Chrome didn't exist. Some major bank websites blocked Mozilla by User-Agent. When Mozilla and Mozilla users got in contact with those banks, the banks demanded the ability to block autocomplete for their login forms. Several times afterward, when people wanted to fix autocomplete, the banks had an effective veto with "we'll block you". At the time, Mozilla didn't have nearly enough market share to say "no, that's our users' decision".
See https://bugzilla.mozilla.org/show_bug.cgi?id=63961 for the history.
This causes many problems for app devs to work around this broken policy. StackOverflow is full of silly tricks from field naming to odd JS. Wasting time
What's the use case for not allowing autocomplete?
Getting 25% fewer users to continue through the funnel. https://news.ycombinator.com/item?id=11911434
Very nice, except when you have something that is explicitly not a conversion funnel. Admin functionality being a big one
This is the use case where the web page should not interfere, thereby enabling the user to use their password manager. You can't even log in to eBay using 1Password any more. That's ridiculous.
Perhaps what is needed is autocomplete="secure" where the browser will only autocomplete after challenging the user for a master password.
I prefer to use LastPass for password/form autocomplete, and disable the browser's autocomplete entirely.
This enhancement just encourages me to use Chrome less. It looks as though I'm in the minority here, however
I used to solve this "security" feature by patching the Safari binary to ignore the attribute. Became too much of a hassle to chase that, but I seriously resent site developers who think they know better than I how I "should" be entering data on my machine.
Seriously - a number of the complaints on both sides of the issue in this thread point to this. Running a lab and have a problem with autocomplete remembering passwords? That's should be a site-specific setting. Have a physical issue with typing, and use assistive software? The browser should have a setting to get out of the %$&^@*% way. Run your own machine securely (by whatever standards you choose to judge that)? It shouldn't be eBay's, or Apple's, or Google's decision how you choose to type your password.
While I'm ranting, I'm seriously sick of a particular strain of arrogance mixed with refusal to take responsibility that emerges in these discussions. I recently had a discussion where a UX person confidently told me that they did, in fact, know better than I on a similar topic. OK, fine; here's a use case in which it seems that you're wrong. "Well, we can't cover every case; we have to plan for the 80% scenarios".
You know my needs better than I, but refuse to take responsibility when you're wrong? Sounds like a good time to show a bit of humility and allow the user you apparently think so little of to make a choice.
I come off the opposite end, where this browser thinks it knows the data I want to enter better than I do. It doesn't. Neither do developers. I just want to use my browser plugin and ignore them both.
For what it's worth, 1Password worked to log into eBay for me just now. Safari 9.1.1, 1Password 6.3.1.
There does seem to be a bit of an arms race with some web sites, though, where the sites manage to break 1Password (whether intentional or not, I'm not sure) and then 1Password fixes it on their end. I wouldn't be surprised if eBay was broken and then got fixed.
Confirmed. Works for me now too. I must have been in one of those gaps in the arms race when I last experienced it.
A few devs posted their use cases here: https://bugs.chromium.org/p/chromium/issues/detail?id=587466
I've had massive problems with it for CRUD apps. Whenever you created a new user it would fill in the values from the first user you created on that system. Annoying as hell.
The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.
When you have your own javascript driven autocomplete that provides more accurate/context specific suggestions.
1) The default design of autocomplete makes your app look really bad.
2) There is an input for searching by name, email, etc. And you don't want it to auto fill with the users credentials.
Google's Search input field has autocomplete="off" setting. This is one of the popular use case I think.
A field named 'email' isn't necessarily for your email.
Apple has popularized the save field on edit model, so autofilling fields can potentially destroy data in a crud type app.
If you have a field for the user to change their password, you don't want to autofill it with their current password.
OTPs. By definition they are different every time.
If the app expects the value of the field to be blank because that is what it was set to, then Chrome auto fills it, but it doesn't generate onChange events. So the app never knows the form has a value.
Not a use case, but Chrome bugs out when an input gets moved with CSS translate() and the autocomplete is open. The autocomplete stays in place unchanged while the input zooms off.
Even if that wasn't the case, a well design form element that animates (transition in a game) looks very different to a deafault-autocomplete I can't turn off.
This is taking away choice. No more.
The webhook form on github has autocomplete=off. Chrome prefills the hook URL with github username and the secret with my password.
The browser is clearly doing the wrong thing.
I fully support the decision by Chrome. I hate when forms try and force it off and get me to type the same thing over and over. It's an abused attribute.
I see this as a good thing. Far better to streamline password management than to make it bumpy, encouraging users to use memorable passwords, which most likely will also be painfully weak.
It's a good and sane default.
I'm trying autocomplete='sudo-off' now. It's not really semantic, but it does get across my intention.
(in this case, a new user form designed for a current admin. Sometimes the site developer really does know more than the browser)
I think you mean "pseudo".
No, he meant "sudo"
https://xkcd.com/149/
http://www.explainxkcd.com/wiki/index.php/149
Seems like a stretch of a joke.
It would make more sense, if you were familiar with the Unix command line. Pretty much whenever something tells you "Permission denied", you just retype the same command with "sudo" before it and then it does what you want. And yeah, that definitely happens often enough to be a running joke among Unix users.
"We announced during the Chrome Dev Summit in 2015 that when Autofill is enabled we see 25% more forms submitted than when it's disabled [3]."
In other words, 25% more users will make it to the next stage of your conversion funnel if autofill is permitted.
That's a reason to turn on autocomplete in your signup form, not to force it on in the browser.
That would be a negative user experience, given the prevalence of legacy forms on the web. Example: "Why does this autocomplete feature fail most of the time?"
"and of you're using a form for something other than a conversion funnel, well screw you"
I'm going to side with the Chrome team on this one. There's very few occasions when autocomplete being disabled makes sense, the vast majority are just developers dumping it in there because they want to make doubly-sure the user actually entered a field by hand (e.g. email addresses) and often for vaporous reasons like "Improve Data Quality," "Stop Spammers/Bots," and "Make sure the user enters the right data in the right box."
Ultimately if you want to assure data quality then use data or format validation, or verification (e.g. send an email with link). If you want to stop bots/spammers use captcha.
We did go through a period where people were "misusing" standard input boxes for other things and autocomplete would ruin that extra usage. But hopefully we've moved beyond turning an input box into a richtextbox using a complex array of hacks, and can now instead use things like Canvas.
PS - Hopefully they disable "smooth scroll" scripts next. So tired of having my scrolling ruined by "helpful" sites.
True, perhaps. The point is that's not for Google to decide. In their example with CRM system, it's very possible that the developer did think about it, and decided that autocompletion would "help" the user enter wrong data.
Now Chrome forces you to be non-compliant to work-around to their "custom feature".
Chrome is increasingly encouraging developer behaviour that's reminiscent of Microsoft and Internet Explorer 6.
It's not for the developer to decide any more than the browser. It's up to the user.
Except there's no ability for the user to disable autosave on a page specific basis.
So if autocomplete breaks functionality then there's nothing the user can do if the developer assumed autocomplete='off' would continue to work.
Except disable autocomplete on every site, which is kind of overkill.
Developers should not expect that things specced as hints will be treated as authoritative direction and should not make software that breaks if that unreasonable expectation doesn't hold.
There are lots of examples.
I'll give one. A text input for a chat you're having with someone. It's very very offputting and irritating to have the browser constantly cluttering the UI with suggestions about what you might want to type in that chat box before you press enter.
Message input field for chat/forum would typically be <textarea>. For example - have a look at reply page source right here, on HN.
And <textarea> doesn't auto-complete regardless of explicit options.
Chat input is typically single-line, submit-on-enter. Messaging apps seem to be transitioning to optional multiline but the default action for enter still seems to be submit so it's perfectly reasonable to use <input> for chat input.
Well, inline chat, like IRC is generally a single-line input... though I suppose you could use a textarea rows="1" and strip \n on paste, etc, that wouldn't be too bad as you're likely listening for \n to post the message anyway.
Either way, not using a typical name/id for the text input would probably work better in terms of not getting suggestions...
That would indeed be the norm for forums. But not for chat. Real time chat is typically more usually a single line entry. Having auto-complete on that is irritating and utterly spoils the UI.
What are those (seriously, I can't think of any off the top of my head).
I know of one from a previous project. We had a prompt that said "enter your home address" with JavaScript autocomplete using google location APIs. Unfortunately chrome would try to auto fill this box with a city name (not even the full address) and this auto fill prompt sat on top of the JS drop down.
Wouldn't making it a textarea w/ rows=1 work? AFAIK textarea is not completed.
So we're back to hacks to replicate a feature that browser developers have decided to ignore? Gotta love web technology.
If "just use a textarea" is a valid solution, why did Google even bother not honoring autocomplete?
Well, the web technology is a pile of sh.t and in this case with the textarea you don't put your hands as deep in to is as you'd with the text input. That's how I interact with the web technology.
It's just amusing, that's all.
Prediction for the future:
1. Google implements auto-complete for one-line textareas
2. Web developers create textareas with 2 lines but hide the bottom line with CSS and disable the return key
3. Something so diabolical even I can't think of it
Yea that's a good idea. I don't like it because it's hacky, but if that's the only option... ¯\_(ツ)_/¯
That's a bug in autocompletion -- if it had autofilled correctly, with the full address -- there would be no discussion here.
If autocompletion had worked as intended, everyone would be happier than if it was disabled.
In our user management portal, whenever tech support opens the Create New User or Reset User Password page Chrome helpfully fills their administrative password into the user's password field.
So in your user management portal, you assign new users or replace your lost passwords with passwords you set, thus you know? Oh my days! Generate it randomly and mail the user, or better, mail them a link to reset/create password page. Otherwise, just make it a plain input field, because if you know it, it's not hidden anyways.
Every hurdle vs. proper security has been non-technical. Slowly making progress :-)
Any search box where you want to hit a backend server and do typeahead searching.
Edit - for a good example, google use it on their search box.
The irony is when I have to hand-enter my email address, especially on my phone, I'm far more likely to mistype it and make a mistake... And on the receiving side, I'm sick of seeing emails for someone else.
Reminds me of the good old days of making things work with IE6.
Sure you do. Then why is commenting closed?[1]
[1]: See the "Restricted- Only users with EditIssue permission may comment." box on the left pane.
From the post:
Commenting is open at https://crbug.com/587466.
Ah! Well that's what I get for skimming through the post.
I stand by the IE6 comment though.
'The semantic meaning' hack is bad for readability. You don't actually mean 'new-user-street-address' you mean 'do not autofill this input chrome.' The next developer in will assume the semantic meaning accomplishes something, and decorating your markup with things that may or may not do nothing seems is bad practice.
Some years ago we had trouble with autocomplete. Browsers would fill in credit card details and customers would call us where we've got their credit card details from. Or they we're completed into a different website and people called us why we gave the other website the CC details.
I actually find this particularly annoying working for a service aimed at elementary schools.
Our user base is almost entirely shared desktops / Chromebooks in schools. Not all school admins are smart enough to disable password saving / autocomplete (not to mention not all schools have someone for this) so we see cases of a kids account getting misused because it was saved on some library desktop all the time.
Give users the option to opt out, but taking the power out of the app developers hands by default is short-sighted.
We have a similar issue in the quality management space.
Multiple quality folks on a shop floor accessing a QMS from the same machine. If an IT admin forgets to disable password saving, compliance rules could be broken if one quality member has the ability to electronically sign a document using someone else's saved password.
Why should app developers have the power by default? It sounds to me like you're arguing for that just because that happens to be what you have trouble with. But I'm sure we can find plenty of other people where having the default be the other way would work better.
Your actual problem is that your users can't change even the most basic settings, and you're not in a position to change it for them. I'm sure autocomplete isn't the first nor the last symptom you'll have due to this problem. Good defaults are important, but good defaults are about more than what works for shared desktops in schools with clueless IT people.
A platform the app developer can't secure isn't a good platform for a secure app.
It speaks negatively of the web over a native app for this to be disabled by default.
What you raise is a valid concern, but letting websites decide on enabling/disabling auto-complete is solving it entirely wrong way around.
If local admin is incapable of configuring user accounts, how are websites supposed to figure out who is who, and which browser is on shared computer?
After all, if managing user accounts is too hard for said admin (or we are talking about a shared PC in a library, which doesn't have user accounts as a matter of principle) - just make browser always start in private/incognito mode on shared computer. It is as easy as adding command-line argument "--private-window" for firefox or "--temp-profile" for chrome. That's it. Window closed - autocomplete gone. Problem solved.
Assumes a competent, dedicated local admin is on staff. This is not the case at about 75% of the SMBs I've come into contact with over the past two years
Modern operating systems have a guest mode which doesn't preserve state across sessions - if they cannot manage something this easy, everyone should be using a guest login.
Websites will always have the ability to disable auto-complete though. Just now it will be though a series of ever-increasingly insane hacks found on StackOverflow (culminating in a custom JavaScript textfield with broken accessibility/internationalization)
Quoting from the actual Google reply:
If you would read what they actually wrote you would notice that - as usual - the headline does not even remotely catch the complexity of the problem.
So how would allowing a small percentage of web apps to disable autocomplete resolve this? It only makes it slightly less painful for the websites where autocomplete is disabled - everywhere else you have the same problem. You're asking the wrong people to solve this for you here.
Are there any browsers left that haven't long ignored autocomplete=off for password fields? Chrome did that some time ago, as did Safari and Firefox.
This change is for all input fields.
This definitely warrants reporting on the followup bug that was listed at the end of the linked bug: https://bugs.chromium.org/p/chromium/issues/detail?id=587466
I was wondering why my Pizza Hut login process got a lot smoother.
Horrible. There are cases when autocomplete="off" is necessary to improve user experience. It's sad that such policies are defined by people not familiar with web development enough to know such cases.
Also, some forms will become inconsistent when autocomplete="off" is ignored (radio button filled by autocomplete instead of the value specified by developer, but the related text input field is disabled as specified by developer).
Moreover, it's a standard. Everyone was complaining about Microsoft when it introduced non-standard HTML and Javascript semantics. Now Google does that.
Are there any cases which can't be handled by autocomplete="okay-google-really-off"?
It'll be amusing if this creates an arms race where Google ignores more and more autocomplete values, until someone just makes an Apache/nginx extension which just gives them a random value.
Chrome 60 will now calculate the entropy of the value, and if it appears to contain more entropy than typical strings it will ignore the value and whack the programmer on the head.
Turning it off in other browsers? What do other browsers do when they don't understand the setting? If any of the others say "well it doesn't say off, so let's leave autocomplete on" then you're a bit screwed.
Considering how the entirety of web development works, you could probably just include both values and then the browsers would figure out themselves which one they want to listen to.
i love autocomplete and i hate when the page tries to turn it off for no logical reason. I have an extension installed that forces autocomplete on for everything.
Good riddance. Now can we please start ignoring:
There is a chrome extension for that (NSFW name) https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
Banking websites do this. I cannot stand it. Thanks.
It is like they want to prevent people from using password managers and strong lengthy passwords!
In some cases because their legacy systems can't support long passwords. I know my previous bank was restricted to 6 digits (maybe even just 4). Their solution was to add in those annoying security questions like "What was your first dog's name". Sigh.
I use Diceware for those things, in case I have to use them over the phone. "My dog's name is effervescent mandible egg voldemort; my mother's maiden name is regent utterly busted harpy"
I called Schwab once because a LastPass misstep locked me out of my account. The CSR told me it was great that I was using a password manager and that she wished more people used them.
I guess it keeps her employed ;) But on a more serious note, banks are not as stupid and anti-technology as the average HN reader wants to believe. Their programmers are no doubt here too.
(Now why Schwab limits me to an 8 character password... I don't even want to know. But I do have a _good_ 8 character password ;)
On that topic, how about the ability to disable manipulating of copied text (is there a name for ctrl+c injection?)
Okay, aside from what you think about being unable to just turn off autocomplete, those semantic tabs actually sound super useful, and i hadn't known about them.
Um, "new-user-street-address" does not appear in the list of recognized values from the WHATWG spec that was linked to above.
How do we find the list of values that Chrome actually recognizes and what they mean?
Am I missing it somewhere else? How does Chrome expect devs to use something completely un-doc'd?
You elided the relevant sentence:
They're saying that they don't autofill when they see autocomplete values which Chrome doesn't recognize, so if you don't want autofill, they suggest you just put in a description of what this field is, which won't be recognized. The functionality is the same as if you put in autocomplete="foobarbazquux", but it's better-described.
Ah, thanks, I didn't do it on purpose, I was just confused. Because:
How is a value not allowed by the spec "valid" as they say? They're encouraging you to violate the spec to trigger chrome-specific behavior (can't really say what other browsers will do when spec is violated, can you?), really? Or does the spec say you're allowed to make up new values too? i don't _think_ so, but maybe I missed that part (not being sarcastic).
It was my understanding that currently Chrome doesn't support any special behaviour for custom values of the autocomplete attribute. I think they just want to get people used to this and probably start capturing data (via web crawls) of what values people actually use to decide what to implement in the future.
ignoring standards worked for IE.
Google's own Search field:
oh....
autocomplete="off" and autocomplete="both" really strange.
One is `autocomplete`, the other is `aria-autocomplete`.
It's tough to say that Chrome made the right call, as I enjoy being able to (in theory) rely on browsers aiming to be standard compliant. The standard is there for a reason, no?
I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin
The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo.
You can play with this yourself: http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script)
My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.
It's not just Chrome. Safari[1], IE and even Firefox[2] haven't respected it either for quite some time.
[1] http://stackoverflow.com/questions/22636673/safari-saved-pas...
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=956906
Probably best for the 99%. I suppose for the 1% they could consider a flag?
Good idea. What if we include an attribute in the form itself. I propose "autocomplete" You can set it to "on" or "off" depending on your needs.
I think it is necessary for some fields to have autocomplete="off" for PCI compliance (login/password field if I remember correctly). So this creates the interesting situation where I should set autocomplete to something else so that chrome doesn't complete it, but that would result in a failed compliance check.
Yes. PCI is a silly substitute for actual security. But the alternative is that many banks and their partners will run with no security because bank executives as a class are firmly opposed to sharing authority with competent IT security people.
This is one cost of their class solidarity.
I have some pages with passwords but not usernames, and chrome keeps trying to treat it as a login, picking an arbitrary nearby field as username, and ignores all markup suggesting otherwise. It's on my todo list to figure out something that bypasses its stupidity, like setting it to a normal field with a weird font, as it's not necessary to prevent copying out of the field.
This is one of the few cases where I'm actually in favor of Chrome's rogue behavior, though I think they're probably doing it for the wrong reasons. I've been annoyed one too many times by webpages that refuse to allow me to autofill login credentials from my browser, to the point where I had to keep a js bookmarklet to strip that attribute from every element on the page. I always hated that it took such a hacky solution to do something which is so simple, and resented sites that attempted to take that ability away from me.
So to me, any change which puts control back in the hands of the user is a good one. I suspect though that the motivation is mostly to "increase engagement" rather than to empower the user.
Google Internet Explorer.
Might as well adopt the name now, rather than later.
I've noticed that a great deal of secure websites will disable autofill in their username and password fields on purpose. For ages I've had a Chrome extension installed that disabled autofill=off to get around exactly that, and I believe I'll leave it enabled. I know better than to trust plain password auth anyway, and mostly use the feature to remember one-time passwords to things like forum sites that have the ridiculous policy of hiding plain URLs to non-registered users. (I will never understand what a forum gains by having a large number of users in their database who registered once to download that one attachment, then never came back again.)
Regardless of the intent, I think when you try to make decisions on behalf of your users, you're doing them a disservice. I mean, really, the security risk of autofill on password fields is that the user's passwords are now saved on their computer? I think users who need to utilize this feature and have it denied them will just end up typing the password into a word document named "Passwords.docx," and that's a heck of a lot less secure than Chrome's encrypted password store. Not that Chrome's implementation couldn't be better, but still.
Why use a Word document? I put all my security passwords—especially the ones that won't autoflll or that make me change them often—into a Google Docs spreadsheet online. That way I can get to my passwords from anywhere.
Trusting users over developers will lead to less security overall. In this case it will make providing intranet access to employee owned devices a little less secure or less user friendly (by blocking chrome)
Firefox has been doing this for quite some time now: https://bugzilla.mozilla.org/show_bug.cgi?id=956906
Here's a huge reason why this is bad. Our company let's you set a "global password" to lock your site. Chrome was auto-filling the password site silently, and exposing people's personal passwords to their whole team when they saved. I understand wanting control, but... Sometimes this is horrible behavior.
Why isn't that a bug in your application? Unless you're building a password manager, passwords should never be shown to someone else. If you need the ability to let multiple people do things, they should still perform the action using their private credentials so you'd have accurate records for who initiated the action.
No, it's an outward facing password to preview non-live sites, like Shopify or Squarespace have. More of a beta code than a password.
Why don't you use, you know, a password field for entering that password?
We did, which caused the problem. (We had a "show password" option, but even if we didn't, it'd still be visible in the HTML)
Seems reasonable to me.
Except, Google themselves now do "google-chrome-autocomplete-off" and "both" and similar values instead.
We just replicated the PHP or IE situation with mysqli_real_surely_this_time_it_works_escape_string or autocomplete="sudo-off".
That's clearly a suboptimal practice by Google's web team. Which doesn't make Google's Chrome team wrong, but maybe the latter should have a word with the former.
Well, there’s no alternative.
You don’t want the Google search box, or the hidden textfield in Google Docs, or so, to autocomplete.
Sure, there is. You could do a meaningful semantic autocomplete tag that isn't one of the recognized ones, rather than a variant of "no, really, don't autocomplete this". (Actually, "body" is probably not a bad practice, but the other one was.)
Dude, we've already told you.
So many ugly hacks are needed as a consequence of this.
I know what I want my app to do better than you Chrome. Please don't purposely break the Internet.
When I try to do user management. I can't call the fields `username` or `password` because Chrome will attempt to autofill it with the saved user/pass from the login. So annoying. :(
Also, it doesn't trigger onChange events when it gets autofilled. :(
This breaks Angular because the field's value is different from what Angular thinks the field's value is.
Isn't a chat a better and more common example than a CRM system? You don't want to autocomplete your old chat messages.
It feels like the solution here is to have a serious-business flag for chrome like phabricator does. Is the browser working for me or is it just helping me work for someone else? That seems to be the real intent problem here. I feel for all the CRM types and data entry people that are going to struggle with this. The user may decide that they don't want autocomplete for a page but they may not be sophisticated enough to turn it off in a meaningful way, or for a particular site.
I still think it's really troublesome that it invents a user-side data store of potentially sensitive data that they really had no say in.
Good. It's taken far too long for user agents and web standard to remember that the intent of a user agent is to be an agent for a user, not something that an external server can dictate with pixel perfect precision.
I'm not very familiar with autocomplete behavior, but does this work across domains? on hidden fields?
Would this help <malicious website> or even <legit website but with malicious tracking intents> to extract information without my consent?
How is this going to work with honeypot fields? Chrome will autocomplete hidden fields like this:
Where "phone" is the honeypot field. Not shown in-browser, so usually only a bot will fill out the honeypot field, sending a strong signal that the form is an automated/spam request.
Of course, autofill messes this up. So the more correct implementation is to turn it off:
But if an autofill of "off" is ignored this technique will no longer work, as the user's browser will fill in the honeypot field.
Based on the OP you would use:
The way I understand it, it's not that autocomplete can't be turned off, it's that "off" no longer turns it off. You can still turn it off in plenty of other ways.
Another possibility would be to add two fields dynamically via JS at load, the first populated at load with a timestamp when the form was loaded... then add onkeyup/onfocus/onclick events for the other form fields, and when triggered populate the second field with the current timestamp.
From there, you can compare the numbers, offset from the current time, and do other checks. I mean, you might want to allow for up to an hour of drift, but most people won't sit on a page for an hour then hit submit.
Though it would be circumvented easy enough, if it's custom, would worry less about it.
Also...
It's ok, most bots are smart enough to avoid invisible fields. This probably hasn't worked in 5 years.
If you follow the link to the next discussion it quickly becomes pretty clear that it's a bad idea: https://bugs.chromium.org/p/chromium/issues/detail?id=587466
Anyone who has to fill forms for other people is going to end up putting his own personal information into the fields by mistake.
The one that I wouldn't mind changing is when the site somehow blocks pasting a password into the field. Yes, I'm not typing it because I use a password manager thank you very much!
Google isn't the new Microsoft, it's the new Halliburton.
The rationale for ignoring autocomplete=off makes sense to me. What I don't understand at all is the suggested "workaround" for disabling autocomplete:
So essentially they encourage authors to make up random, nonstandard values for the attribute that may or may not do what the author is hoping for.
I don't see what this will archieve except making the autocomplete attribute a pain to use in practice.
(Which might be what the Chrome team intends, but even then, a more straight-forward and more honest way would be deprecation.)
No, they are encouraging you to give more meaning to your fields. For the example given of a CRM app, using customer_email_address as the input field makes much more sense than using a standard value for email address, as the two fields are asking for different things: The latter always wants your email address, whereas the former wants the relevant email address for the record you're viewing/editing.
But there is no guarantee all sites will use the same values or even give the values the same meaning: One might write "customer_email_address", another "e-mail-address-of-customer". A third one has separate input fields for the parts before and after the "@" and uses "email-address-name" and "email-address-host" respectively...
So in the end, if everyone followed the advice and used "semantic" values, this would likely lead to the same problems that HTML already had with semantic class names, rel values and meta tags. The discussions about them fill mailing list archives. I don't see why all this should be repeated, even more so as the problem of semantically annotating your elements is already solved.
But in this case it's even weirder as that was presented as a way to tell Chrome "please don't autocomplete". So if that's the real motivation, then sites are likely to just put some variant of "really-really-off", or just random strings in it without any regard to "semantics".
I can't resist the feeling these were specifically developed by the User Data Mining department.
Chrome, IE11[1], and Firefox[2] all do this, and have for a while.
[1] IE11 does not support the attribute at all http://lists.w3.org/Archives/Public/public-webapps/2014JanMa...
[2] Firefox ignores it too https://bugzilla.mozilla.org/show_bug.cgi?id=956906
Both of those apply just to ignoring autocomplete settings for password management, not other input fields.
That's different from Chrome not giving effect to autocomplete=off for any fields.
Would you ever want autocomplete on, say, a field where you're inputting a 2FA response? Probably not, since any suggestions would be useless.
I find the workaround of "just put some other random bullshit for the value" hilarious. And once developers start over-abusing that as well (they will), then what's the plan?
One of the commenters on the linked bug to discuss valid use cases for autocomplete=off hits a wonderful nail on the head:
I wish I had been able to find this a few weeks ago. Was working on a modified login feature where the autocomplete behavior was actually a hinderance to a UX improvement we were working on.
Not making a comment either way on whether they should be doing this, but ... I think we all know what's going to come next :(
How long before somebody uses that to guess your physical address by creating a page with input field named 'address' and so on just to read their values with JS?
The problem is you can't read autofill values with JS. This leads to a horrible experience for users when you have say an Angular form that gets autofilled and they click submit and it tells them the form is missing data.
But would it be possible to send the values using ajax to server side?
Disappointing. I don't use Chrome, so for me it's difficult to even believe such thing is possible
For the love of FSM, why is it that browser vendors are always so f%!#ng arrogant?? It's not just Chrome, we've seen this attitude from Firefox devs before as well: "fuck you, we know more about what you meant than you do".
I really wish somebody would fork either Chromium or Firefox and commit to delivering a browser that just fully, completely and accurately implements the various specifications, instead of trying to "improve" them like this.
I wrote this extension a long time back: https://chrome.google.com/webstore/detail/docomplete/onlplld...
It removes "autocomplete[off]" from all input elements.
Pretty sure that Satan's minions invented auto-complete as a vector for side channel crypto vulnerabilities.
The weird thing is, `autocomplete=off` _does_ seem to have the intended effect on my Chrome. OSX 50.0.2661.102. Huh? Was this change made in a later version I haven't gotten yet?