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

Issue 468153 link

Starred by 177 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

autocomplete=off is ignored on non-login INPUT elements

Reported by, Mar 18 2015

Issue description

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

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. 


In comment #100, 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.
Showing comments 65 - 164 of 164 Older
IE also agrees with FireFox that the value should be "off" not "false". See
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

Comment 69 by Deleted ...@, Aug 4 2015

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

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 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.
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. 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 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? 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, 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, 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:

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

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, Nov 25 2015


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.
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, Dec 3 2015

The following revision refers to this bug:

commit 570de6587cd3a56da12d5b234e97ea1e31355f45
Author: sebsg <>
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:

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


Comment 124 by, 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, 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, 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, Feb 11 2016

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

Comment 155 by, 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 , 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, 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, 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, Mar 3 2016

Still and issue and causing a lot of pain and frustration for developers who need this functionality:

In our case, autocomplete prevents AngularJS form models being updated. Y'know AngularJS - from Google.
Labels: -Needs-Feedback Restrict-AddIssueComment-EditIssue
Status: WontFix (was: Untriaged)
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: 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.

Showing comments 65 - 164 of 164 Older

Sign in to add a comment