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]|
    +---------------------------------------+

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.

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.

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.

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.

And <textarea> doesn't auto-complete regardless of explicit options.

Either way, not using a typical name/id for the text input would probably work better in terms of not getting suggestions...

What are those (seriously, I can't think of any off the top of my head).

If "just use a textarea" is a valid solution, why did Google even bother not honoring autocomplete?

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

If autocompletion had worked as intended, everyone would be happier than if it was disabled.

Edit - for a good example, google use it on their search box.

    <input class="gsfi" id="lst-ib" maxlength="2048" name="q" 
    autocomplete="off" title="Suche" type="text" value="" aria 
    label="Suche" aria-haspopup="false" role="combobox" aria   
    autocomplete="both" dir="ltr" spellcheck="false"
    style="border: none; padding: 0px; margin: 0px; height: 
    auto; width: 100%; position: absolute; z-index: 6; left:
    0px; outline: none; background: ....

autocomplete="off" and autocomplete="both" really strange.

[1] http://stackoverflow.com/questions/22636673/safari-saved-pas...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=956906

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.

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.

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.

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.

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.

It speaks negatively of the web over a native app for this to be disabled by default.

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.

This change is for all input fields.

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

  onpaste="return false;"

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

    <div style="display: none;">
        <input type="text" name="phone">
    </div>

Of course, autofill messes this up. So the more correct implementation is to turn it off:

    <div style="display: none;">
        <input type="text" name="phone" autocomplete="off">
    </div>

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

    <div style="display: none;">
      <input type="text" name="phone" autocomplete="section-honeypot nofill" />
    </div>

    <div style="display: none;">
        <input type="text" name="phone" autocomplete="honey-phone">
    </div>

This really makes me uncomfortable, standards are there for a reason, you don't just ignore them because you don't agree with them.

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

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.

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.

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

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

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.

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.

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

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.

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

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.

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.

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

This is one cost of their class solidarity.

The other problem - that we mostly managed to workaround - is that AngularJS and some browsers' autocomplete didn't go along very well.

2) There is an input for searching by name, email, etc. And you don't want it to auto fill with the users credentials.

Apple has popularized the save field on edit model, so autofilling fields can potentially destroy data in a crud type app.

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 browser is clearly doing the wrong thing.

Perhaps what is needed is autocomplete="secure" where the browser will only autocomplete after challenging the user for a master password.

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.

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.

This enhancement just encourages me to use Chrome less. It looks as though I'm in the minority here, however

    //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() . "'>";

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.

From the post:

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

Commenting is open at https://crbug.com/587466.

I stand by the IE6 comment though.

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?

(in this case, a new user form designed for a current admin. Sometimes the site developer really does know more than the browser)

https://xkcd.com/149/

http://www.explainxkcd.com/wiki/index.php/149

Anyone who has to fill forms for other people is going to end up putting his own personal information into the fields by mistake.

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

Dude, we've already told you.

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 a good and sane default.

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.

Seems reasonable to me.

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.

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

In other words, 25% more users will make it to the next stage of your conversion funnel if autofill is permitted.

Would this help <malicious website> or even <legit website but with malicious tracking intents> to extract information without my consent?

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.

[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

That's different from Chrome not giving effect to autocomplete=off for any fields.

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.

  ...
  "language"
  "bday"
  "bday-day"
  "bday-month"
  "bday-year"
  "sex"
  "url"
  "photo" 

It removes "autocomplete[off]" from all input elements.

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

See https://bugzilla.mozilla.org/show_bug.cgi?id=63961 for the history.

Might as well adopt the name now, rather than later.