New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 170 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: WontFix
Owner: ----
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
autocomplete=off is ignored on non-login INPUT elements
Reported by jonathan...@gmail.com, Mar 18 2015 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36

Steps to reproduce the problem:
1. In Chrome > Settings > Advanced > Passwords and Forms, check "Enable Autofill to fill out web forms in a single click"

2. Using omnibox, navigate to https://hub.securevideo.com/Support/Autocomplete

3. Right-click > View Page Source. Confirm that this is a trivially simple HTML form, where the autocomplete="off" attribute is specified for both the FORM as well as for all INPUT elements.

4. Type the first letter of your name, e-mail address, or phone number in any field

What is the expected behavior?
Because autofill="off" is specified for the FORM as well as all INPUT elements, I would expect the autofill not to occur.

What went wrong?
Autofill occurs for all elements.

Did this work before? N/A 

Chrome version: 41.0.2272.89  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 17.0 r0

This is a huge problem for the usability of my web application. Javascript-based typeahead widgets are completely blocked by the autofill box, and my support team is reporting that users have unexpectedly submitted information due to autofill. 

See https://code.google.com/p/chromium/issues/detail?id=352347

In comment #100, jww@chromium.com states "As mentioned earlier, this only ignores autocomplete='off' for *password* fields. Any other field where autocomplete='off' isn't respected is most likely a bug, and we would very much appreciate you filing a bug over it."

This is that bug filing.
 
Comment 1 by jww@chromium.org, Mar 18 2015
Cc: gcasto@chromium.org vabr@chromium.org
Labels: Cr-UI-Browser-Passwords
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.
Comment 3 by vabr@chromium.org, Mar 18 2015
Labels: Cr-UI-Browser-Autofill
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.
Comment 4 by vabr@chromium.org, Mar 18 2015
I just checked the reproduction steps from comment #0 on a clean profile in Google Chrome, 41.0.2272.89 (Official Build) m, and I could not reproduce.
Comment 5 by vabr@chromium.org, Mar 18 2015
In #4 I forgot to say that this was on Windows.
Cc: rponnada@chromium.org
Labels: Needs-Feedback
@ jonathantaylor290, As per comment4#, 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
Comment 8 by vabr@chromium.org, Mar 18 2015
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 comment #100 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.


Comment 10 by Deleted ...@, Mar 18 2015
i can reproduce and confirm this issue for Chrome Version 41.0.2272.89 (64-bit) on OS X Yosemite Version 10.10.1 (14B25)
Labels: -OS-Windows -Arch-x86_64 -Cr-UI-Browser-Passwords
Status: Untriaged
see bug 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.
Comment 22 by Deleted ...@, Mar 23 2015
How exactly do we handle forms that allow users to enter "1 time data"?  Let's say there is an address book, and there is a form that will let a user enter data for multiple contacts using the same fields, address, email, phone, etc.  I do not want the browser to bug the user into autofilling the values.  In this case, I as the developer know better than the browser to disable autocompletes. 

It is really annoying also, that we have invested in the ability to provide "typeahead" type functionality for city, state, zip codes, but the browser is now displaying the autofill popup over the typeahead popup provided by our applicaition.

Comment 23 by Deleted ...@, Mar 26 2015
Letting chrom(e|ium) ignore the autocomplete="off" setting is one of the dumbest and most unacceptable decision I've ever seen!

Jonathan in comment #12 has said it all.

You (the chrom(e|ium)) team(s) are ascribing us that we're too stupid to make correct use of this setting in our forms. Unfortunatly there are hundreds of usecases, where automatic fill in by the browser surely is not wanted.

One very prominent example is a typeahead field for autocompleting data from a database. Actually, the Chrome auto-fill-in feature hides the typeahead feature of the field and you (the user) has no chance to choose the correct entry.

Please don't assume us (the developers of web applications) to be too stupid to decide if the auto-fill-in feature of the browser is needed or not.

Give us back the control over this feature!
Summary: autocomplete=off is ignored on non-login INPUT elements (was: autofill=off is ignored on non-login INPUT elements)
Echoing especially comment #22.  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).
Comment 30 by Deleted ...@, Apr 7 2015
This is causing huge problems for us because we use our own custom autocomplete for a user's location. This creates problems for google's own autocomplete places javascript:

https://google-developers.appspot.com/maps/documentation/javascript/examples/full/places-autocomplete-addressform
Comment 31 by Deleted ...@, Apr 16 2015
As for the confusion that Autocomplete != Autofill. They might be different Chrome features, but the HTML spec doesn't help the confusion by using the term "autofill" explicitly in reference to the "autocomplete" attribute: https://html.spec.whatwg.org/multipage/forms.html#autofill

Regarding actual Chrome Autofill: It seems that Chrome tries to be too clever in guessing what specific form fields are for. Going as far as looking at the <label> element and even using synonyms, such as taking "Location" to mean "Country". 

Real world problem caused by this: A field with <label>Country code</label> for an input element with name="cc" and maxlength="2" will be auto-filled with the user's full length country text saved in their auto-fill settings, despite it being obviously too long for the field and being named only similarly.

As for autocomplete="off" being ignored, you can get around this problem by setting it to pretty much anything else (as per the spec link above) I can specify a different context such as autocomplete="country alpha2". This seems to stop Chrome knowing better than the developer and the user as to what should go in the field. 

To go back to the original purpose of this thread: If Chrome Autofill will observe these "Autofill detail tokens" then why not observe "off" when it's part of the same spec?
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.
Comment 33 by Deleted ...@, May 15 2015
What joe said, it's driving me nuts.

Anyway, chrome won't try to autocomplete an input[type="search"]
Issue 489027 has been merged into this issue.
I think comment #31 is spot on, and corrects an erroneous statement in comment #29 by est...@chromium.org.

In comment #29, 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 ;)
Comment 36 by Deleted ...@, May 27 2015
I'm having the same problems as everyone else – I've built a custom autocomplete-widget for a client, used for address lookups on a central database, and now they can't really use it as Chrome puts it's own autofill-options on top of my widget content.

#31 said it best: please respect autocomplete="off", especially when no password fields are involved at all. Otherwise, if you want to make up your own standards, you might as well just run with it and slab a big, blue "e" on top of the Chrome logo.
Comment 37 by Deleted ...@, Jun 15 2015
Still no news?

How I am supposed to prevent this ?


Capture d’écran 2015-06-15 à 13.50.45.png
48.4 KB View Download
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??
Image 366.png
75.7 KB View Download
Comment 40 Deleted
To latest developers to post on this thread: I implemented the workaround I described in comment #14 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.
Comment 45 by Deleted ...@, Jun 30 2015
One use case where respecting autocomplete="off" is important is on Google's own Autocomplete Address Form in the Google Maps Javascript API. Here, addresses can be autofilled or selected from Chrome's address dropdown instead of selected from the Google Maps dropdown and passed to the Autocomplete object. In other words, Chrome's default renders Google's own API less user friendly:

https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete-addressform

Interestingly enough, autocomplete="off" is respected in the much more complex Places Autocomplete example, and in Google Maps in general:

https://developers.google.com/maps/documentation/javascript/examples/places-autocomplete

A fix would be greatly appreciated!
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!
Comment 47 by Deleted ...@, Jun 30 2015
Thanks! Changing the input type to "search" did fix this.
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.
Comment 50 by k...@mix.co, Jul 1 2015
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.
Comment 51 by Deleted ...@, Jul 3 2015
Please learn from Internet Explorer, don't ignore widely accepted useful standards. Change the default flag to disabled and resolve this.
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 :)
Comment 53 by glad...@gmail.com, Jul 8 2015
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. 


Comment 54 by Deleted ...@, Jul 13 2015
Thank you #14 jonathan...@gmail.com 

That workaround is awesome!
Comment 55 by shaun...@gmail.com, Jul 13 2015
@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" />
Comment 57 by Deleted ...@, Jul 14 2015
The biggest problem with all these work arounds are the inoperability with third-party libraries/frameworks. 

The best workaround I've found so far is <input type="search" ... however this falls down if you have a JS library that is searching for DOM elements by their type i.e. $('input[type="text"]')

The workarounds that involved changing the name/id attributes of the field are good in the terms that they keep the field type correct, however they could still throw off (or cause alot of work to be needed) JS libraries or backend frameworks such as Ruby on Rails
Comment 58 by krelo...@gmail.com, Jul 16 2015
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'.
Comment 59 Deleted
Comment 60 by Deleted ...@, Jul 23 2015
Thanks a lot for the solution in #14. Having set autocomplete="address-level4" is disabling autofill. I would agree  that there needs to be a elegant way to achieve this. The image in #39 makes it so obvious that there should be a element way to disable autofill. The Chrome autofill blocking the app's typeahead is destroying the good user experience. 
Comment 61 by aldut...@gmail.com, Jul 27 2015
what a weird bug, please fix it. I am currently using the autocomplete="something else" solution

Comment 62 by Deleted ...@, Jul 29 2015
Our application has been broken by this behaviour. We used typeahead to improve user experience, and Chrome's choice to ignore autocomplete/autofill attribute is no sense.

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


Comment 69 by Deleted ...@, Aug 4 2015
tl;dr
Google also knows that the correct value should be "off"; comment #44 pointed out that there is a flag specifically turning off the functionality in the standard.

In addition, a workaround (though ugly) was posted in comment #14 and reiterated in #41.
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.
Comment 71 by mcf...@gmail.com, Aug 5 2015
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.
Comment 75 by ncjo...@gmail.com, Aug 5 2015
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.
Comment 76 Deleted
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
Comment 78 by Deleted ...@, Aug 15 2015
This is a problem.  Our site offers searching for addresses and phone numbers. We use bootstrap typeahead (bloodhound) for entry of states and city names.  Unfortunately, the Chrome autocomplete is displayed over the typeahead display, partially obscuring it.  I (and every other user) is entering other people's addresses and don't need Chrome to suggest their own!!!

I (nor my users) don't want to turn auto complete off completely.  It is quite useful when I'm shopping and such.  If Developers overuse the autocomplete=off tag, then address that problem with the community, don't just ignore it!!!  Personally if a store has automplete turned off and I have to renter my address and such, it is an opportunity for abandoning the sale, and this will correct itself.  If a store turns it off because they get too many misshipments due to wrongly autocompleted information, shame on the browser.

The caching of passwords is a whole different discussion and much longer.

Please fix this!!
Has there been any change in this or work around ?
Comment 80 by Deleted ...@, Aug 25 2015
Any workarounds with Honeypot fields in mind? Because that's the only thing that we use it for and our clients are loosing valuable leads to spam because autofill keeps triggering it even with autocomplete="off".
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.
Screen Shot 2015-08-31 at 14.39.52.png
404 KB View Download
Issue 527408 has been merged into this issue.
This issue has taken its toll, Please Google resolve this ASAP
Comment 84 by Deleted ...@, Sep 8 2015
As for a single user that has only one account on a website this Bug is useful.

But for somebody who has to deal with dozens of accounts daily this bug is really annoying. Please fix this bug.
Comment 85 by aall...@gmail.com, Sep 8 2015
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.
Comment 86 by Deleted ...@, Sep 8 2015
Google, fix this issue ASAP.
Comment 87 by Deleted ...@, Sep 8 2015
applying a default value to input fields i.e. value="&nbsp;" seems to fix this issue. Empty values do not seem to work though. 
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.
autofill-fail.png
23.0 KB View Download
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.
Comment 96 by Deleted ...@, Oct 9 2015
I also confirm this issue. Only way to solve it was by doing what comment https://code.google.com/p/chromium/issues/detail?id=468153#c41 says

I tested on Mac. The form is inside a popup window, not sure if that affects
Comment 97 by Deleted ...@, Oct 13 2015
This issue has now reappeared... Which means things like billing postcode, which refreshes shipping methods on input become useless. Auto fill should atleast perform trigger an .on('change')
Comment 98 by Deleted ...@, Oct 19 2015
Please fix this issue. Google map address does not work correctly with google distance api and google lat/lng if address are pre-filled. 
+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.
Comment 101 by Deleted ...@, Oct 22 2015
Dear Chrome team, You are wrong to assume everyone wants Autofill. What if the website wants to implement it's own typeahead?
I find Chrome autofill doesn't work correctly anyway. I have to double check every field, fix phone numbers, copy address lines to the correct spot. I used to use autofill but now it just doesn't seem to work. And while I'm venting what's the deal with Chrome's resource usage? Why run every tab in a new process? The security reason doesn't make sense.... if a webpage compromises Chrome it can see every other user process anyway. You guys have too narrow a focus and are starting to make the wrong decisions. 
Think about what users want, not how to win pwn2own! Anyway I've uninstalled Chrome at my home for these reasons, but I still have to support it at my workplace.
Comment 102 by jbo...@gmail.com, Oct 29 2015
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".
Comment 105 by mi...@mavn.is, Nov 15 2015
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 comment #11: "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 comment #17: "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.
Comment 112 by Deleted ...@, Nov 18 2015
This completely ruins address lookup on my website.
Comment 113 by Deleted ...@, Nov 18 2015
"enabling better user experiences"
Untitled.png
16.8 KB View Download
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
Comment 119 by Deleted ...@, Nov 25 2015
If a dev wants to disable autocomplete, let them. Even MS respects the spec https://msdn.microsoft.com/en-gb/library/ms814860.aspx 

I'm building a site where a private login for clients allows them to login to a client area with information protected by NDA/SLA/etc - I, and neither do my clients, want information freely accessible here because someone left their computer unattended.

Also, this is ignored: (separate but similarly ignorant issue that does NOT improve UX)
:-webkit-autofill { background-color: ANYTHING !important; }
// hax (obv can't be transparent):
:-webkit-autofill { -webkit-box-shadow 0 0 0 500px white inset; }

Chrome is becoming the new [old] IE.
Comment 120 by vabr@chromium.org, Nov 25 2015
Cc: -vabr@chromium.org
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. 
Project Member Comment 123 by bugdroid1@chromium.org, Dec 3 2015
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

Comment 124 by mi...@mavn.is, Dec 3 2015
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?
Comment 128 by Deleted ...@, Dec 3 2015
I wished this whole thing worked the other way around: autocomplete="off" should be the default behaviour of all browsers. We shouldn't have to set this on all our fields now, it's noise. If you want a field on your form to support autofill, then you need to add autocomplete="on". There usually aren't many of those, while the number of fields where you don't want autofill is far greater.
Comment 129 by Deleted ...@, Dec 4 2015
I make admin interfaces for wireless routers for a major network technology company. On our interface, a user logs in as an 'admin' and then they can configure the router. One screen allows them to enter a username, password that logs them in to another service across the internet. With the current chrome behaviour, if the user sees autocomplete and just saves they will send their PRIVATE local username/password across the internet to a third party service. How can this obvious security flaw and leak of information be seen as a legitimate behaviour and not a bug. The Chrome team's attitude towards this reminds me of how the IE team used to behave when they had the greater market share. New boss , same as the old boss indeed.
Comment 130 by Deleted ...@, Dec 4 2015
In addition to my previous comment, our interface also allows a user to save a list of access point username/password combinations and edit them in a table. With the current behaviour, the user has to constantly clear out the password files for each row in the table. How on earth is this considered 'correct' behaviour and what gives the browser developer the right to impose this on  web app developers? 
Yay! Thank you!
Comment 132 by rov...@bigml.com, Dec 13 2015
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 134 Deleted
Comment 135 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 140 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 143 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.
Comment 147 by rov...@bigml.com, Feb 1 2016
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 153 Deleted
Comment 154 by val...@gmail.com, Feb 11 2016
Shame on you Chrome team!!! Fix this bloody bug!!!
Comment 155 by slip...@gmail.com, Feb 11 2016
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 ?

Comment #123 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!
Comment 160 by gs0...@gmail.com, Feb 24 2016
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).
Comment 163 by d...@room9.co.nz, Mar 3 2016
Still and issue and causing a lot of pain and frustration for developers who need this functionality: http://stackoverflow.com/questions/12374442/chrome-browser-ignoring-autocomplete-off

In our case, autocomplete prevents AngularJS form models being updated. Y'know AngularJS - from Google.
Labels: -Needs-Feedback Restrict-AddIssueComment-EditIssue
Status: WontFix
First off, thanks for everyone's feedback on this. I apologize for our delay in clarifying our stance. We've been working to finalize our policy regarding Autofill and the autocomplete attribute, and we've been making changes to this over the past few months (as some of you have noticed).

First and foremost, Autofill in Chrome exists to help our everyday users get through common forms (address forms, contact forms, checkout forms, etc) across the web. This has become especially important on mobile devices, where typing on virtual keyboards is both difficult and annoying. Autofill tries to make this experience better, and it's used millions of times per day by Chrome users.

The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn't mean there aren't very valid cases where you don't want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data [1].

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.

We encourage developers to take advantage of Autofill. We announced during the Chrome Dev Summit in 2015 that when Autofill is enabled we see 25% more forms submitted than when it's disabled [3]. Users find high value in Autofill, and we want to encourage users and developers to continue to take advantage.

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.

Again, thanks to everyone for your comments. We look forward to continuing the conversation.

[1] https://support.google.com/chrome/answer/142893?hl=en
[2] https://html.spec.whatwg.org/multipage/forms.html#autofill
[3] https://www.youtube.com/watch?v=m2a9hlUFRhg&feature=youtu.be&list=PLNYkxOF6rcICcHeQY02XLvoGL34rZFWZn
Sign in to add a comment