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)

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.

(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)

They seem to have fully understood and carefully weighted the implications.

> 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.

> [2] https://html.spec.whatwg.org/multipage/forms.html#autofill

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?

This. Exactly this. Now you have an attribute value that works in some browsers and the exact opposite function in other browsers, and the only way to switch between it is server side rendering based on user agent or javascript attribute value modification based on user agent at render time. No option to have the browser choose functionality based on the markup alone. Welcome back IE6. We missed you. Thank Google for creating more Web Designer jobs!

> The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

So the other browsers are part of the WHATWG, and a new spec got defined. I don't see any problems here.

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.

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.

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

(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.)

    autocomplete="section-disabled disabled"

[1] https://html.spec.whatwg.org/multipage/forms.html#autofill-d...

Of course when it comes to buying things online give me my autocomplete or I hate you

- love your recommendation for a browser prompt!

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?

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.

(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?)

That leads to some random behaviour.

This works so much better than the behavior other browsers use.

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.

This is an interesting observation. I never used the "wand" function in Opera because, partly, it's named in such a way as to not appeal to power users at all. The name "wand" says "do something magically". Agreed that "wand" doesn't indicate what it does, which is another reason to shy away from it. It's such a generic term as to be useless. Literally anything could be behind the "magic" operation.

Another thing I forgot to mention which is quite important. It works well when your password store is encrypted. It allows browser to ask you for your master password when you are trying to log in to the page, not when you happen to visit page that password is stored. This makes feasible to use configuration where the password is forgotten either immediatelly or after few minutes. Having encrypted password store in FF or Chrome and not storing the password all the time in memory is essentially unusable.

Not sure about the newbie argument, yes it might be like that in the beginning, but you won't stay newbie forever you learn things. Also I'm not buying the minimalist argument, Chrome currently is one of biggest resource hogs among browsers.

Anyway at least provide option to enable such behavior. On Firefox I use Secure Login extension to emulate that, but it doesn't work as well as Wand did.

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.

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.

Have I been confusing autocomplete with auto-fill this whole time? Autofill where, let's say you shop on a site often, and you fill out one form field, select a saved entry and the rest of the form fills out?

Mostly on sites that both have traditional login forms and use forms where other fields are mis-identified as password fields.

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.

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.

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.

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.

Wouldn't that just override whatever values Chrome throws in there anyway? (If you're using JS.)

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. :(

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.

... 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

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).

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.

javascript:void(document.onmousedown=null);void(document.onclick=null);void(document.oncontextmenu=null)

If it breaks websites you use then your only option is to completely disable autocomplete.

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.

And nothing prevents us from dropping, on ~/.js

    setTimeout(() => {
      Array.from(
        document.querySelectorAll('[autocomplete]')
      ).forEach(
        el => el.removeAttribute('autocomplete')
      );
    }, 250);

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.

<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.)

You say "bug", they say "works as designed".

(This is not actually my personal stance, just playing devil's advocate.)

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.

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.

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

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.