Chromium

gcasto@ or vabr@, can you take a look? Thanks!

Yes! Please respect the developer's code. And update the password manager to respect the URL of the form where data was saved, so a customer saved on http://mydomain.com/login it won't autofil on http://mydomain.com/edit/customer which it currently does.

Thanks for the report, jonathantaylor290.
I'll try on Windows soon, but when checking on Linux, doing exactly the 4 steps as above, I could not reproduce this issue, neither with 42.0.2311.39 (Official Build) beta (64-bit), nor with the tip-of-the-tree Chromium build.

I'll update this ticket with what I see on Windows.

In the mean-time, adding the right labels, because this is rather concerning normal autofill than password autofill.

I just checked the reproduction steps from https://crbug.com/chromium/468153#c0 on a clean profile in Google Chrome, 41.0.2272.89 (Official Build) m, and I could not reproduce.

In #4 I forgot to say that this was on Windows.

@ jonathantaylor290, As per https://crbug.com/chromium/468153#c4#, issue is unable to reproduce. Could you please re-check this on clean profile and issue is still exists, please provide a screen-cast will help in triage further.

I can confirm the issue on both linux (chromium 41.0.2272.89) and windows (chrome), for me happen in this case:

in the login page a user save his credentials,

then the user navigate to another page, for example to edit an item that has username and password (unrelated with the ones user for the login) if the username match the one used in the login page the password is automatically setted to the one used for the login process.

This obviously cause unexpectedly submitted informations.

Additionally the form has autocomplete="off"

My workaround is to set the password field read only and then make it read write with a timer, but this is an hack, this is a browser bug.

Please try harder to reproduce is quite easy, thanks

drakkan1000: Please not that this bug is not about password fields. It is explicitly about non-password field autofill.

MORE DETAILED REPRODUCTION STEPS
================================
1. Uninstall any existing version of Chrome, including deleting browsing data

2. Install Chrome from www.google.com/chrome, set as default browser. Confirm version 41.0.2272.89m (or later) is installed.

3. In chrome://settings > Advanced > Passwords and Forms, confirm that "Enable Autofill to fill out web forms in a single click" is checked

4. Navigate to https://hub.securevideo.com/Support/AutocompleteOn

5. Fill in the 3 boxes with your name, e-mail, and phone number, and click "Submit"

6. In a new tab, open the same page (https://hub.securevideo.com/Support/AutocompleteOn), now type the first character of your name, e-mail, and phone. Confirm that autofill functions properly.

7. Now navigate to https://hub.securevideo.com/Support/AutocompleteOff, and fill in the 3 boxes with the first character of your name, e-mail, and phone. Confirm that autofill does not occur, which is correct for this page, because it has autocomplete="off" for the FORM and all INPUT elements.

==> Next, you can use either Steps 8 and 12, or Steps 9-12.

8. In chrome://settings > Advanced > Passwords and Forms, click the link "Manage Autofill settings". Add your name, address, e-mail address, and phone number. This simulates what will happen over time as the user visits web sites and enters information. Go to step 12.

               - OR -

9. Login to chrome using any existing profile which, on any other computer, has any addresses present in chrome://settings > Advanced > Passwords and Forms > Manage Autofill settings. Most existing profiles will have this information present on some other computer. Note that the addresses may not be immediately present on the freshly installed Chrome yet.

10. Go to https://hub.securevideo.com/Support/AutocompleteOn, and fill in the 3 boxes with the first character of your name, e-mail, and phone.

11. Back in "Manage Autofill Settings", confirm that the addresses have now been imported for the profile to which you have logged in.

12. Navigate to https://hub.securevideo.com/Support/AutocompleteOff, and fill the 3 boxes with the first character of your name, e-mail, and phone.


Expected result: because autocomplete="off" for both FORM and INPUT elements, and this is not password data, the autofill feature should not engage, per jww@chromium.com in https://crbug.com/chromium/468153#c100 of https://code.google.com/p/chromium/issues/detail?id=352347.

Actual result: the autofill feature engages. This can be devastating to usability. In my case, it hides typeahead widgets (such as Bootstrap or JQuery UI), which renders crucial input fields unusable in my application.

see https://crbug.com/chromium/425672

The example form given above at face value looks like something that Chrome /should/ be autofilling, but it's just a toy example, so it's hard to reason about. That is, how does Chrome know if autocomplete="off" is there for a good reason for this form? The problem is that autocomplete="off" is far more often used for poor reason than good.

If you link me to your actual form it would be easier to analyze the dilemma. Your best bet at the moment may be to use <datalist>.

The production form is hidden behind a login, but uses a typeahead where the user is selecting a recipient to videoconference with. It is the main functionality of our web application, securevideo.com, with thousands of customers. The list of recipients can run into the hundreds, which makes using a dropdown impossible. Without the typeahead functionality, we would have to present a search box, click for results, and then select, which is far too cumbersome. Datalist could work in some cases, but unlike the jQuery UI and Bootstrap typeaheads, it is not supported in any Safari version or in non-HTML 5 browsers.

The reason I believe this is a bug is because the Chrome behavior here is not consistent. The autocomplete either comes from the Settings Addresses, or even if there are no Addresses in Settings, autocomplete will still work. Try the following steps:

1) Delete all addresses from Settings
2) Go to https://hub.securevideo.com/Support/AutocompleteOn
3) Fill out the form twice, and observe that the value submitted the first time IS available the second time
4) Go to https://hub.securevideo.com/Support/AutocompleteOff
5) Fill out the form twice, and observe that the value submitted the first time IS NOT available the second time

Here, Chrome is respecting autocomplete="off". But if Chrome should follow your argument that "autocomplete='off' is far more often used for poor reason than good", then autocomplete="off" should NEVER be respected by the browser. However, we see that autocomplete="off" is respected in some cases (when the source of the autocomplete is a prior page load) and not in others (when the source of the autocomplete is the Settings Addresses). To me, this is a bad inconsistency.

One more distinction to make: web sites versus web applications. Web sites that people visit once or twice, and have to enter information, it probably makes sense to always help users with autofill. However, for web applications, where people are using all day, every day, it makes sense to optimize the application for productivity and ease-of-use, and there really should never be a need to autofill in a web application. Or at least, the developers should be trusted to be able to turn autofill off for any one of a number of good reasons. From reading the Chromium issues related to autofill, there is quite the furor from the developer community about Chrome ignoring autocomplete="off". Many developers are quite upset, and I can understand why. The difficulty is that I suppose the browser cannot easily distinguish between the web site use case and the web application use case, and as you say, many web sites will turn autocomplete off when it should be left on.

For now, we are advising the users who call our support team to use Firefox and not Chrome due to this issue. However, I would prefer to recommend Chrome to my users, and would like to beg for Chrome to trust its developers and respect autocomplete="off", or at least come up with some attribute like webkit-autocomplete="off", or allow explicit mappings between form fields and autocomplete fields, where a particular autocomplete field could be set to "name", "address", "phone", or "off".

If you fix this quickly, I think literally hundreds or thousands of developers would jump up and down for joy and want to kiss the entire Chromium team!

We do have a way to explicitly map inputs to types: https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute

Thank you for this. It seems everything in that spec works except for "off" ;)

An ugly workaround I just found but I'm pretty sure some folks reading this will use--at least until it stops working a couple of weeks after a Google developer reads this:

1) Set one of the three fields to have autocomplete="address-level4", leaving autocomplete="off" on the other fields

2) Observe that every _other_ field now has disabled autocomplete, except for the "address-level4" field

So the practical workaround would be to assign autocomplete="address-level4" (or some other rarely-used autocomplete field) to a HTML INPUT element that you don't really care about.

I guess this is my strongest argument for making autocomplete="off" work properly: if autocomplete="off" is not respected by the browser, then the world will soon be littered with workarounds as ugly as this (and I have seen some much uglier attempts when searching the web) by unhappy web application developers.

Yes, that is a workaround, but hopefully the ugliness of it causes developers to stop and consider if they should really be disabling the feature. The ugliness and obscurity of this workaround is the price of enabling better user experiences across all the pages that abuse autocomplete="off".

I still think datalist is the way forward, although it's currently not as functional as you might like it to be or available on as many browsers as it should ;) be.

What pages actually *abuse* autocomplete=off? I mean, come on. Usually it's set there intentionally to improve usability and/or security.

There is a general consensus within Chrome that there are no security benefits to autocomplete="off".

The security benefits are arguable, but the usablity drawbacks from removing autcomplete="off" are not, especially when you don't have a good enough logic in place for autofilling forms. Either you fix the logic so it's _flawless_ in all use cases, or you bring back autocomplete="off" and give control back to the developer.

While autocomplete="off" may have no security benefits (besides preventing uber-sensitive data from being stored and readable within browser-settings), removing the functionality adds no security either.

> Either you fix the logic so it's _flawless_ in all use cases

We're working on this --- patches welcome :) If the problem is Chrome misidentifying  fields, then you should use autocomplete="[datatype]".

I have a coupon field during an ordering process (name="coupon") that Chrome autofills with the username from the login form to customers controlpanel. How do I fix that, if not with autocomplete="off"?
You removed autocomplete="off" too soon. Fix autofill, then consider removing autocomplete="off".

Two ways:

1) (doesn't work yet) -- autocomplete="coupon-code" --- we'd have to petition WhatWG to add this type or a similar one to the standard. Chrome would ignore this field as it doesn't attempt to remember coupons.
2) (should work) --- mark the rest of the form that the coupon code is in with appropriate autocomplete= values. Leaving the coupon input alone.

[Empty comment from Monorail migration]

Echoing especially https://crbug.com/chromium/468153#c22.  I have an application that stores contact information for users: names, postal addresses, phone numbers, email address, for hundreds of people.  Without the ability to disable autocomplete, the browser wants to present autocomplete entries relevant to the browser user, which have nothing to do with the form being filled out.

The browser is making assumptions that are completely wrong. There needs to be a way to shut it off. If the Chrome team feels so strongly about it, then make a way for the web application to request no autocomplete for a given form ID at a given URL, and allow the user to accept that, upon which the browser will remember it and obey autocomplete="off" directives going forward.

Could you please consider reverting the autocomplete="off" change, until autofill is perfected? It's doing so much damage at the moment.

It seems that autocomplete="off" just makes the submited value of that input to not be stored in the autofill store.
But Chrome doesn't disable the autofill feature for that input when the autofill store has matching values for that input. Those values will be displayed in the autofill dropdown. The values submited for that input with the autocomplete attribute set to "off" are not shown in the autofill dropdown.

The autofill feature shouldn't be enabled for inputs with autocomplete="off".

Chrome users may want to "safely" and "conveniently" store their credit card info into Chrome (and the Google system).

But please let me decide as a developer/service provider if I allow user submitted data to be stored on the user computer (the autofill store) when the user visits my service online.

I don't want the autofill feature to kick in on a public computer.

There seems to be some confusion in this thread.

autocomplete="off" is NOT respected for Autofill data, whether saving or filling. You can see your Autofill data in chrome://settings/autofill. It includes addresses and credit cards.

autocomplete="off" still IS respected for Autocomplete data, both saving and filling. I know the terminology is confusing. Autocomplete data simply tries to match the name attributes. So if you have entered "user@example.com" into an input with name="email" in the past, and Chrome sees another name="email" input, Chrome will offer to complete that data. However, autocomplete="off" will stop this from happening.

> I don't want the autofill feature to kick in on a public computer.

If you admin a public computer, you should make sure autofill is disabled (by policy).

This really sucks. I want to implement my own autocomplete with jqueryui autocomplete plugin, but heavy handed google knows better and forces their own auto suggest which obscures mine making it unusable.
more and more google heavy handedness makes me hate them. I used to think Chrome was the best browser but not when it does this crap.

[Empty comment from Monorail migration]

I think https://crbug.com/chromium/468153#c31 is spot on, and corrects an erroneous statement in https://crbug.com/chromium/468153#c29 by est...@chromium.org.

In https://crbug.com/chromium/468153#c29, it is written: "autocomplete="off" still IS respected for Autocomplete data, both saving and filling"

While this may be (and should be) the design intent, it does not happen. If autocomplete="off" is used for every field on a form, that setting is not respected for any field.

If one field has something like autocomplete="country" and the rest have autocomplete="off", then all of the autocomplete="off" fields are respected.

To me, after all this conversation, this is simply a bug that would probably take a lot less time to reproduce and fix than to keep arguing about ;)

My issues with autocomplete="off" being ignored is with usability.

When a field is populated via autocomplete/autofill, javascript events that would normally be fired if an actual user was filling the field are not fired or not consistent across all browsers.  Rather than have to fight with each browser provider to do the right thing (i.e. inform the user via a javascript event that a field has been autofilled/autocompleted), it is easier to disable the feature.

Additionally, there are certain fields in web applications where I want the user to think about the data they are entering, rather than the value be autofilled into a field that they might not even think about if it's been autofilled for them.

This is just pathetic.

I have spent countless hours to find a workaround with no success. Why Chome, why??

[Comment Deleted]

To latest developers to post on this thread: I implemented the workaround I described in https://crbug.com/chromium/468153#c14 nearly three months ago, and it has worked perfectly since then. While we would all prefer that "autocomplete=off" function properly at all times, it still functions properly if you include in your form an input element with any other autocomplete value.

I simply added this code to my layout:

<div style="display: none;">
 <input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>

Once I did this, all of my "autocomplete=off" elements were respected by Chrome.

Hey Google,
You know the web browser is the universal client in modern client server architecture.
What if I'm building a data entry app, do you really think it is helpful to suggest the user's address over and over while interfering with the app developers ability to suggest input based on the actual context in which the application is used.
I guess you don't want us using chrome for such cases.
Stop being so arrogant and heavy handed. I am really sick of the way google always thinks they are right about everything and force their opinions on us.

and no I don't want to sprinkle hidden inputs all through my html for a workaround that is bogus and may or may not not work in the future and is specific to chrome browser. I want google chrome to respect my application and that means if I put autocomplete off respect it as other web browsers do.
Please fix this!

Google really is falling apart with their design and UI experience stuff.  For millions of web uis this is a disaster.  

The issue is that the "ignore autocomplete='off' (Autofill)" flag is set to enabled by default in chrome

chrome://flags/#ignore-autocomplete-off-autofill

Doesn't seem like a great idea to have the default behavior to ignore a standard.

Google should fix this. A temporal workaround, specially for Google Maps address autofill is to change the input type to "search" as pointed above, but we shouldn't have to be searching for workarounds! This is not hard to fix! Just respect the spec!

Please make this work. As a couple(few?hundred?) developers have stated here, I want to make suggestions to the user from our internal database for city, or county, for example. The current implementation in Chrome makes this all but unusable - workarounds suggested about (type='search', hidden fields) don't seem too work, except maybe intermittently.

My forms work perfectly in Firefox and Safari - hell, they work in IE! There's something, I get to recommend IE over Chrome to our clients! Joy. I would love to see a fix for this.

While ignoring the autocomplete setting seems like a good idea for home users who are ordering things, it can be horrible for those in a work environment which input hundreds of address into web forms weekly.

Also doing something like type="search" isn't a great workaround because that changes the keyboard layouts on mobile and tablet devices.

Please just swap the default behavior of the flag so the default is to honor the autocomplete setting. This is especially important the desktop.

Another comment in favor of simply reverting this behavior to honor the intent of the standard. This is a serious problem for my internal and external users entering data via Chrome, and while it may be possible to go in and tweak the flags for the folks in my office I can't very well require thousands of external users to do the same.

i have a modal with form input elements bound to a keyup event, so i can update a div in real-time with the text entered into an input. i noticed today that because of the autofill/autocomplete bug, that if a user selects an autofill suggestion, the keyup event doesn't get fired, i.e. if i enter this text into an "email" input:
example

and "example@example.com" comes up as a suggestion and i click on it, then the div i'm updating only shows "example", so i ended up having to bind a "blur" event to the inputs too bc chrome wasn't respecting the "autocomplete=off" setting.

please let the developers decide, and follow the web standards, thx in advance :)

This is an absolutely horrible user experience; the expectation that the web is only used to input form data for yourself is extremely short sighted.  This should be reverted; we are correcting more data that is incorrectly "helped" the user with than is being entered correctly.  The workarounds are terrible.

@jonathan...@gmail.com
Thanks for the detailed fix in #41, it works perfectly to fix my typeahead issue.

Google,
We still need to be able to utilize autocomplete="off" feature  across all the browsers. The issue will just explode when more developers start using "typeahead" fields.

this also seems to work:
<input type="text" id="noRespect" name="noRespect" autocomplete="respectMyAuthoritah" />

Dear lord, thank you for the work around in #41 - Somebody said it's 'ugly' -> and to that dear Frodo I say "NOT as @#$ ugly as a bunch of stupid options destroying our typeahead search box".

Man autocomplete is great .....where it makes sense (thinking forms), man it's horrible where it doesn't make sense (I'm thinking auto complete search boxes working against dynamic data).

#41 workaround, I embrace you as my child, you are ugly, but you do beautiful things. I love chrome, but man, talk about forcing cubes through my eye sockets....

'.. cradles #41, butterfly kisses and all'.

what a weird bug, please fix it. I am currently using the autocomplete="something else" solution

Just bumped into this issue.  I can confirm that it fails on 43.0.2357.134 (64-bit) MacOS 10.10.4 (14E46).

Please fix this bug (yes, it is a bug even if you guys deny it.)

This is a significant bug, because, as others have mentioned, it hides other autocomplete lists attached by the user code.

At present there is a work around for this: Namely to set `autocomplete="false"` instead of to "off". However, there is a significant problem with this: setting it to "false" DOES NOT turn it off in FireFox.

The correct value for turning off autocomplete on an input is to set the attribute to "off". See https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

Please fix this as a priority.

IE also agrees with FireFox that the value should be "off" not "false". See https://msdn.microsoft.com/en-us/library/ms533486(v=vs.85).aspx

It actually seems to work with autocomplete="off" in the very last versions of Chrome. It didn't a few weeks ago. The situation is a bit confusing, a clarification would be welcome =)

Still tries to autocomplete with a <form autocomplete="off"> in 44.0.2403.125

this needs to be solved - with new web technologies and big data an increasing number of input fields has a custom autocomplete list - these custom autocomplete lists are hidden below the chrome autocomplete and therefore unuseable.

even W3C agrees, that "off" is the right value for turning auto completion off and not "false" - see http://www.w3.org/TR/2011/WD-html5-20110525/common-input-element-attributes.html#the-autocomplete-attribute

Neither #14 nor #41 are proper solutions - I can't get all end users to change their browser settings and #14 is simply an ugly work-around which might stop working any time without prior notice. Google should comply to the standard - if a developer decides to disable autocomplete he might have a reason for doing so.

The problem is that often the developer doesn't have a good reason, he just thinks his site is more important than everything else, and prevents autocomplete on login pages, leading to the bad user experience that chrome is making up for here.

Well, I'm sure that's a problem, but the standards are the standards. If every browser followed them, then the bad user experience would be easily linked with the webpage/developer, not with the browser. I mean, if they want to compete with other browsers by not following the standard, that's great! As pointed in #36, they could go check with the ones with the big blue "e" and see how they did last time they tried...

"The problem is that often the developer doesn't have a good reason, he just thinks his site is more important than everything else, and prevents autocomplete on login pages, leading to the bad user experience that chrome is making up for here."

I call bullshit. Developers should be the ones to decide whether to disable autocomplete. I've never added autocomplete=off without good reasons. This is the heavy handed google knows best attitude that pisses me off.

All the excuses to justify what Chrome is doing make my head explode. I thought the "IE" days are over.

There's another fix that people have mentioned in the thread but it seems to have gotten buried. Setting type="search" will trick chrome into disabling autocomplete, although it doesn't work in Firefox.

You're all talking about the developer's point of view, But what about the user. When I have an misidentified field that I can't turn off that's a bad user experience caused by chrome.

Chrome has a tendency to pre-fill/override fields that already Have input in them, And there is no way to tell it that it is misidentifying this field as a user/password field

Has there been any change in this or work around ?

As a developper I want to custom my form as I want. And I certainly don't want Chrome to add this ugly yellow autofill background. It breaks the graphical consistency of my application.
I don't understand why "autocomplete" attribute is not anymore supported!

This is an issue, so please fix it.

[Empty comment from Monorail migration]

This issue has taken its toll, Please Google resolve this ASAP

For programmers this is a nightmare.

When editing user information the data is populated from a database record, if populated correctly and then suddenly because a field name has "password" and/or "username" Chrome populates the field. Of course I am editing another record and it is NOT my credentials belonging in these fields.

Chrome must respect autocomplete=false and/or autocomplete=off to prevent these high risk changes to records not intended to be changed. An end user CANNOT be expected to remember in a brief flash the user name and password of every record they are editing.

It appears this is going to be a "works as designed" until there is a sufficient user uproar.

Unless this gets some attention at some of the larger tech news sites I don't think adding comments is really going to help.

It's amazing that Chrome developers don't see the issue themselves when they actually use chrome.

It's so obvious that autofill and autocomplete="off" is horribly broken, someone should be going "wait, this can't be right, someone should really fix this".

Summary of this issue:
Attr. autocomplete="off" on form or input should disable autocomplete popup on all inputs or one input respectively.

Workaround:
Form need to have one input with autocomplete diffrent then "off"

If any input in form has this workaround, then no matter what other inputs or form have, autocomplete is ignored for all inputs.

Passwords ignore this attribute by design - when using type="password", browser always asks for saving those and fill those (same for FF, IE)

Also site by reporter https://hub.securevideo.com/Support/AutocompleteOff applied this workaround by setting email autocomplete="address-level4".

On our professional networking application, users enter the companies they work for. We use typeahead to display a list of companies already entered in the database from other users. This allows the user to select their company from the list in order to be associated with said company. We can then surface other users from the same company for them to connect with.

Also, as you might expect, many companies have multiple addresses throughout the world. So, when our users enter an address for said company, we use typeahead to offer a list of addresses so that we can further drill down for them.

Chrome's autofill blocks both of these...users end up adding the same company multiple times. They select the wrong address because they assume the correct address isn't there...because it's being blocked by Chrome's autofill!!!

It's a mess. Chrome is the most used browser of our members at 36% so we have to do something. For now, we'll roll with the dirty quick fix in 14/41 (thanks!). Moving forward, we'll never use standard name and id attributes again. Instead, our users will never have the benefit of autofill anywhere on our web application except for usernames and passwords.

Just my opinion: you're not going to prevent bad actors from acting bad...instead, you're forcing all of us to run a race to the bottom.

KendoAutoComplete can´t do is job when the browser uses the autofill feature. It is very confusing for the user to have two competing features fighting each other.

So the chromium teams argument to disregard autocomplete="off" is because it was being misused. And now were putting in autocomplete="respectMyAuthoritah" to work around that. So some developers think other developers are stupid and don't use a feature correctly and now they force them to really abuse a feature. No wonder Aliens keep away from this planet.

as for "confusion" @ #29

1. HTML spec. https://html.spec.whatwg.org/#autofill uses term "autofill" to describe user agent behavior of helping user to fill up the fields. This behavior is driven by 'autocomplete' attribute.

2. Spec. says nothing about how agent is achieving that. Thus dichotomy between "autofill from data entered by user in other forms" and "autofill from data entered at /settings/autofill" is irrelevant to autofill behavior.

3. "[autocomplete=off indicates that user] have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for him; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values."

Ignoring 'off' value for 'autocomplete' attribute for password field is somewhat corner case and out of scope of this issue.
There is no security reasoning to disable 'off' for all other input types.

Please consider to move the issue forward as there are several cases confirming it.

+1 for standards compliance.

In reply to #11:
> how does Chrome know if autocomplete="off" is there for a good reason for this form?

estade@chromium.org: why should the browser be making judgements on that? The behaviour is explicitly defined, and it is a standard HTML feature, not a Chromium feature. If you think the UX can be improved by modifying page behaviour, maybe you should try implementing that as part of the browser UI instead, in the omnibar, a context menu or a minimally intrusive icon somewhere. It should not just go against the spec and modify behaviour because of opinions.

Additionally, how would this scale to other browsers? Will they be able to implement the same algorithm? I understand that some decisions have to be made, but this actively harms users because of overlapping/broken features, and harms the web itself since now everybody is applying an ugly workaround. The browser has no job in deciding whether HTML was written for a 'good reason' or not.

Finally, what is Chrome's recommended way of providing a typehead/autocomplete feature on a website using a standard input field?

#99 quote:
Finally, what is Chrome's recommended way of providing a typehead/autocomplete feature on a website using a standard input field?

I'm serious about this too.

Google is becoming a champion at breaking the Web.

Just because of this moronic 'feature' I had to rename my 'city' field to 'dragonDen' just to get typeahead working correctly. First I tried 'dragonTown' and that didn't even work! Seriously, if an app builder wants to disable autocomplete, let him. Have his users complain to him about the missing functionality if they'd require that. Don't try to fix stuff by guessing if the autocomplete="off" is valid.

I'm having a problem now in all our backends where creating a new or editing an existing user record would result in prefilling data with the agents email if none had been provided before and we're boggling our minds on how we could fix this and so far nothing has worked. As chrome is by company policy the only browser for our agents that is a serious problem and just asking for trouble.

Please act according to the spec and honor the setting of autocomplete="off".

If you're going to differentiate between autofill and autocomplete you must also provide a flag to disable autofill! There are fields for which is it *never* desirable to select the previously used value.

Dear Chrome Developers,

I understand your intentions are good, but you are evidently causing many hours of pain for many developers with this feature. Particularly for manually implemented, database-based typeaheads (see #99).

The latest version of Chrome (46.0.2490.86) appears to have changed behaviour again. This time, AutoFill has nothing to do with 'autocomplete' or 'readonly' or any number of other workarounds suggested on this forum.

Rather, AutoFill now looks at the *label* next to the input box, and generates an AutoFill based on that. So a workaround is to insert junk text into the label inside a hidden span:

   S<span style="display:none">_</span>uburb:

This was the only thing that prevented Suburb AutoFill for me.

Please reconsider this feature. It is causing many problems for many people.

Actually I take that back: AutoFill appears to be using several techniques (label, name, id) to discern the spatial relationship between fields. A big clue is how AutoFill can actually fill multiple fields at once (e.g. Street, Suburb and State).

I found I had to obfuscate the label, plus the name and the id of the field in order for AutoFill to go away.

#99 quote:
Finally, what is Chrome's recommended way of providing a typehead/autocomplete feature on a website using a standard input field?

I'm serious about this too.

@jonathan re #14 workaround: suppose we collectively start using that workaround, with a big enough mass, won't that result in my web application getting things auto filled out based on what a user had entered on your site earlier?

From the Chrome team in https://crbug.com/chromium/468153#c11: "The problem is that autocomplete="off" is far more often used for poor reason than good."

Sure. Especially now that we have to litter all our input fields with autocomplete="address-level4" or whatever other vague option is out there in order to prevent Chrome doing something we don't want it to do. It was just fine before mind you.

An explanation of what is considered a poor and a good reason might be helpful.

From the Chrome team in https://crbug.com/chromium/468153#c17: "There is a general consensus within Chrome that there are no security benefits to autocomplete="off"."

does that consensus extend beyond the walls of Chrome? From the docs:

https://html.spec.whatwg.org/multipage/forms.html#processing-model-3:autofill-field-name-9

"
When wearing the autofill expectation mantle...
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.

In addition, when an element's autofill field name is "off", values are reset when traversing the history.
"

with a nice little example: "Banks frequently do not want UAs to prefill login information:"

We need user agents to respect what it's being told: autocomplete="off" means what it says on the tin, plain and simple. How can there be any confusion about that amongst the Chrome team members?

From #15: "Yes, that is a workaround, but hopefully the ugliness of it causes developers to stop and consider if they should really be disabling the feature. The ugliness and obscurity of this workaround is the price of enabling better user experiences across all the pages that abuse autocomplete="off"."

The reason we're working on this is because we have several customers complaining that fields get auto suggestions which they find factually incorrect within the context of our application and distracting from their workflow. The general consensus is that no field within our application should ever get suggestions offered.

Use case: we have a CRM type web application. Some users have to regularly fill our person and company data. Every time they need to enter data such as a name, email, address, city, state or country they get the suggestion to fill out their own name, email, address, etc. that they've used on some other site when they bought something or filled out a form to subscribe to something. Clearly they never want to enter their own data.

What can we do to help our customers?

To clarify an earlier comment from the Chrome team:

"There is a general consensus within Chrome that there are no security benefits to autocomplete="off""

Fair enough. But what is the general consenus within Chrome as to the *usability* benefits to autocomplete="off"? The developers here are, for the most part, not arguing about security. We are arguing that AutoFill appears on top of (and obscures) our manually-implemented, server-based, typeahead. This seriously affects usability.

Can the chromium teams provide some examples of people who "abused" autocomplete="off"?

If webpages are turning it off where they shouldn't then the market will correct them as users will use other services.

Its all about what #113 posted. Can chrome devs propose any usefull solution to this?

As an administrator, I log in to manage member profiles. Autofill and autocomplete are off and emptied. But when I go to edit profile, it picks up on my earlier login and replaces the members info with my own. This makes it impossible to do anything without knowing every members username and password.

Mac OSX El Capitan, Chrome Version 46.0.2490.86 (64-bit)
No problem when using Safari.

Another use case: we have a form for provisioning devices that require usernames and passwords.  

Since Chrome ignores us when we tell it that it shouldn't be populating the end-user's username and password, it happily populates (and often overwrites) these fields with the wrong data when we load and then populate the form for an update, typically the user's own login.

Whether some people "abuse" this attribute is immaterial.  It isn't Chrome's job to decide whether someone is "abusing" HTML.  The standard defines the attribute and what it does. Let people take up their grievances about "abuse" of the feature with the developers of such web sites on their own.  Or give users the option to context-menu-override autocompletion for forms that disable it, but the obvious choice is always to make the default behavior adhere to the standard.

Dear dev team,

Please rethink this decision. I can think of at least 4 reasons why you should.

1. It will not accomplish the goal of preventing poor use. This thread is proof. At best it will slow it down.
2. It creates a guaranteed new influx of poor use (the workarounds that you are forcing us to use).
3. It is contrary to the philosophy "Focus on the user and all else will follow." There are many examples in this thread of how this creates a poor user experience.
4. Standards compliance

[Empty comment from Monorail migration]

WAKE UP NOW PLEASE.

I build back end business systems. I have a page that is the prompt page to delete a database table. I want authorized users to enter a password and then hit submit to complete the delete.  Simple enough, except chrome is autopopulating my pw field with my login pw...

Seriously.  This is way overstepping reasonable bounds for browser design.
b

it's a issue for sure, why the option  if it is not honoured.

I ran to this with using google places address autocomplete as the autocomplete is hiding the actual places results and is annoying + the autocomplete never fires change events if fields are filled with autocomplete so that's nasty if you need to trigger something on events on field changes. this "does not fire events on fields changed after autofill" is the number 1 reason developers disable this in my opinion.

the way to disable autocomplete was to set a observer on field focus event and just set autocomplete="false" (or anything random instead "off" will do ) on the fly.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/570de6587cd3a56da12d5b234e97ea1e31355f45

commit 570de6587cd3a56da12d5b234e97ea1e31355f45
Author: sebsg <sebsg@chromium.org>
Date: Thu Dec 03 20:54:00 2015

[Autofill] Respect the autocomplete=off attribute on desktop for non credit card related fields and forms.

BUG=468153

Review URL: https://codereview.chromium.org/1473733008

Cr-Commit-Position: refs/heads/master@{#363052}

[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/chrome/renderer/autofill/form_autofill_browsertest.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/chrome/test/data/password/password_autocomplete_off_test.html
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/browser/autofill_field.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/browser/autofill_field_unittest.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/browser/autofill_manager.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/browser/autofill_manager_unittest.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/common/autofill_util.cc
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/components/autofill/core/common/autofill_util.h
[modify] http://crrev.com/570de6587cd3a56da12d5b234e97ea1e31355f45/third_party/WebKit/Source/web/WebFormControlElement.cpp

Why only on desktop? This is an issue on mobile as well.

Almost 7 months, actually 5 lines of functional code and this bug still persist on mobile devices.
Is there any reason why mobile devices should behave diffrently?

Same question here - why should mobile devices behave different?

At least this is a step in the right direction.  Wondering about mobile support though. Are there any plans to support this?

Yay! Thank you!

I'm still having this issue with autocomplete=off being not respected. The funny thing is that this is not a complete "form" I'm only using <input> element without their <form> parent. I've tried with autocomplete="foo" in other fields and autocomplete="off" in the one I don't to be autocompleted is still being filled in. And the funniest: it is only an <input type="password" name="api-key" autocomplete="off"/> it is not the "password" field and it is filled in with the login password from another URL in my site.
My workaround: add this  <input type="password" autocomplete="passoword" style="display:none" />  somewhere in the DOM.

Crhome 47.0.2526.73 (64-bit) in Mac

Are you guys cerial? I am building CRM systems that different people use on the same computer. And I don't want autocomplete to be present, let me do it, please.

[Comment Deleted]

[Comment Deleted]

Sorry Google, this is fucking ridiculous!!

I've got a web app, where I have an "Administrate users" page, where user can type in a new username and password combination, to create new users. When I show my "new user form", it fucking suggests uses MY CREDENTIALS as the logged in admin on the site for "new user credentials".

Fucking respect the standards, or expect to end up in the Microserf corners of the web, and have web developers stop suggesting using Chrome as their browser ...

To not respect autocomplete="off" is simply not OK!!

And that "fix" further up in the comments, basically means every single user visiting my site, gets to download additional DOM and HTML overhead, just to fix a stupid fucking ridiculous bug, sold as a "feature" by your developers ...

Reminds me of the days you had to have two websites, one for IE and another website for "everything else" ...

I have a "set new password" form where I use autocomplete="off" and Chrome keeps autocompleting this fields.

Tt just doesn't make any sense for Chrome to work in that way and not following the markup directions.

I also experience this issue on Windows 7 on Version 47.0.2526.106 m. Please can you let us know where you are with this since it affects the integrity of our web apps.

+1 for all hate against Chrome disrespecting autocomplete="off".

My main reasons as developer ale also: very bad behavior in backend (edit/add users), filling nonsense values to forms containing "name" input even they are not meant as username, etc.

[Comment Deleted]

This was the solution I was able to use to turn off Autofill for a given form:

1) Add autocomplete="off" to the <form> element
2) Add the following element before all input fields in the form: <input type="text" style="display: none" autocomplete="address-level4" />

Obviously this is a total hack and Google needs to come up with a better solution than the one they have currently offered.

Fix this bloody bug !!!!!!!!!!!!!!!!!

[Comment Deleted]

Hello Team,

Please fix this bug, having troubles when trying to re-loop on a method on server side for reseting a user password... autocomplete="off" support will help to reduce amount of code thks.

a dirty hack on client side unlocked me, using javascript with timeout function like:

setTimeout(function(){$('#user_password').val('');}, 50);

All our input fields which do back end searches have problems in chrome due to auto complete popping up and taking over the focus. Sucks big eggs so massively.

I'm guessing there's still nothing from Google/Chrome about having an official fix for this. There are already a number of real usages out there that require a form to now autofill or prompt users with autocomplete options but no response about what should be done in those instances. Bit of a shame really.

hahahaah, with the new version of Chrome (at least in Mac  48.0.2564.97 (64-bit)) they have avoided the workaround using the display:none; input type=password. I have another workaround for this anti-workaround but I won't tell you so they can't avoid it as well.
Come on Chrome Devs, fix this!!!!!!!

Unbelievable that this problem still persists after all this time. I'm switching to Firefox.

We are seeing this issue in our web application in Chrome 48.0.2564.97 on Windows, Mac and Linux.

The problem! fix this guys

+1 on #149 - thought this was fixed but there seems to have been a regression...

Dudes. DUDES! Let's get this fixed

[Comment Deleted]

Shame on you Chrome team!!! Fix this bloody bug!!!

Dear lord, almost a year and nothing. Such simple bug!

Hey guys,

Been a year, any update?

This issue is still in "Untriaged" status, maybe we could at least expect a change there ?

https://crbug.com/chromium/468153#c123 mention a commit on this matter, however the latest canary build is still affected by the bug.

I hate "me too" or "+1" comment, but without any official feedback on this bug, this is the only option I'm left with... Our customers are impacted by this bug and we don't want to introduce (yet another) ugly hack to workaround this browser issue.

All, after reviewing https://html.spec.whatwg.org/multipage/forms.html#autofill , I was able to fix my issue by adding 'autocomplete="new-password"' to each password field I don't wish the browser to autofill.

Can you comment if there's a negative side-effect that I'm missing?

Please fix! For all the numerous rational arguments presented above!

My experience on Chrome browser is, it refers the username/password saved on the cloud, so my workaround is that I go to the "MANAGE PASSWORDS" of https://myaccount.google.com, manually remove the pair associating to the site, reload the page, then the annoying autocomplete is gone; but it looks different policy on Firefox browser.

This is also breaking PCI compliancy. Some fields that are password fields are used for other things like SSN, pass phrases, etc. When a user with Google Chrome uses a form like that, their un-encryted password could be sent into a system where other people will have access to their password. This issue is a big deal for security focused organizations. In the case of the business I work for, when asked next time - we will send PCI auditors directly to Google.

Can confirm this bug still exists in Chrome 48.0.2564.116 Windows 10 32 bit.

This needs to be implemented as it interferes with custom autocompletes like JQuery UI Autocomplete by hiding them (used a lot in cloud apps).