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

Issue 352347 link

Starred by 106 users

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

Issue metadata

Status: Archived
Last visit > 30 days ago
Closed: May 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

issue 375329

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Don't autofill passwords where confirmation is required

Reported by, Mar 13 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36

Example URL:

Steps to reproduce the problem:
I don't know how to reproduce that. But Chrome is ignoring [autocomplete=off] to input[type=password]. And it is bad!

In my systems I need set [autocomplete=off] to FORM. But this is terrible. Since prevents autocomplete necessary in some cases.

Otherwise, I am forced to manually clear the fields in order to avoid having a problem when trying to send a form.

Check images to reference.

Firefox seems works fine (according to this user), check:

Similar case:

What is the expected behavior?
I expect that fields with [autocomplete=off] never suggest auto-completion.

What went wrong?

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes I don't know. But I don't remember that it happen about six months.

Does this work in other browsers? Yes 

Chrome version: 34.0.1847.60  Channel: beta
OS Version: 6.3
Flash Version: Shockwave Flash 13.0 r0
55.3 KB View Download
Showing comments 12 - 111 of 111 Older

Comment 12 Deleted

I understand the change, but this needs to be fixed. It is just plan annoying. I have attached an image of my registration form being auto filled as an example.
43.0 KB View Download

Comment 14 by Deleted ...@, May 9 2014

Detecting multiple password fields does not solve the problem.
Some admin interfaces provide only one password field to change/set a password.

For example, on the attached capture, you can see Chromium completing a pincode with admin credentials.
As can be expected, I also found a variant of the <input type="text" style="display:none" /><input type="password" style="display:none"/> solution.

This problem would be avoided if Chromium did any of the following :
1) ask confirmation before filling the fields.
2) wait for the user to type or click or otherwise select voluntarily the credentials completion.
3) fill in forms that have the same id than the original one.

In this situation, Chromium shouldn't be filling into this particular field.
Filling any password field preceded by a text input is being too invasive.
This forces the admin to check on each form that he dos not enter his credentials at random places.
After a couple of mistake, any sane admin would disable autofill.

There will always be a way to disable or work around autofill.
Please, do not force web developers to use <input type="text" style="display:none" /><input type="password" style="display:none"/>.

44.0 KB View Download
Same problem here in a cms, settings shows username and 2 password fields to optionally change password. Which is being autofilled as login form, causing customer complaints when trying to submit their settings changes, ( passwords do not match errors ). This is a very common pattern.

Comment 16 by, May 20 2014

In support of #9 -- we are only autofilling one password field, right?
If there are multiple password fields, then:
1) how can we be sure to autofill in the right one?
2) how would the user be able to fill the other password field, if they don't know the autofilled password, and cannot copy&paste it?

If we don't have good answers to the above questions, I see not autofilling as the only option.
Blocking: chromium:375329

Comment 18 Deleted

IMHO, the root of all evil is the password manager associating a saved password to **all** password inputs of a given domain, since password inputs can be used for many sorts of things other than user authentication.

I'd suggest that when the browser requires a user gesture to save a password, not only the credentials should be saved but also the path where the login form resides (preferably the forms/inputs IDs if any). This solution may annoy the user while submitting a password input that isn't an authentication operation (e.g. #14 print), but can make sure that the user is able to use the password manager and make the password manager itself less intrusive.

So, that's it, I believe that the key for the solution is to find a way to identify forms that are used for authentication purposes and the user can help the browser with that when he opt-in to save a password.
I'm just now struggling with this issue on the latest Chrome and am completely mind blown by how strange recent changes have been. I completely understand the desire to ignore autocomplete='off', since it doesn't provide much security anyway, but when a user logs in and then goes to change their password their credentials should not autofill.  This is especially bad when credentials are force filled on any input type='passwords'.  In my case, a user is password protecting a file and Chrome is autofilling their username into the date field so that the password input gets populated.  This is completely bizarre and I have no knowledge on how to fix it.

Ok I found a solution.  Just give your input type='password' a value='' attribute.  This prevents the autofill.
Not really, go to the previous input and double click it...

Comment 23 by Deleted ...@, Jun 19 2014

Adding value="" to the field doesn't prevent it from autofilling in my case.

Would it not be wise to tie autofilled values to element IDs on the original form? We have a scenario where credit card details are being autofilled by the login details which isn't great.

Comment 24 by Deleted ...@, Jun 25 2014

Same shing. It breaks the profile editing form. The password fields are hidden by default, the form is submited and users get an error because system thinks that there was an attempt to change the password!
2.9 KB View Download
I am also amazed that this hasn't been addressed still. We provide a SAAS CRM solution and my clients are forced to switch to Firefox because this bug. Not only it ignores the form attribute, it also autofills in wrong places. Amazing. See the email put in the zip code field! And, yes, autofilling all password fields by default is wrong.
Screenshot from 2014-07-09 12:17:51.png
84.8 KB View Download
Screenshot from 2014-07-09 12:21:25.png
90.5 KB View Download
Just do what Firefox does: if the form or field has autocomplete=off, don't autofill on page load, but show a dropdown and autofill the password once the user selects or types the remembered username into the text field.

Comment 27 by, Jul 11 2014

Can someone on the Chrome team perhaps comment on the status of this issue?

It's affecting users of many applications out there. I don't think that developers should be forced to create hacks as a workaround to a browser 'feature' which is behaving incorrectly.
I ran into this issue while upgrading my signin/signup form. It used to work fine, but now Chrome autofills wrong fields of a user registration form which may annoy users and may cause an unexpected result.

I think Chrome team decided to give end users what to autofill, but the problem is Chrome is not smart enough to detect the right fields.

I hope in the next release Chrome, the browser will respect autocomplete attribute so web devs can hint the browser. I would leave sign in form to be autofilled, but not for registration/checkout/etc.

Comment 29 Deleted

Today client started screaming at me because of this Chrome issue.
My web application is the type of the form builder with lot of functionalities. 
What happen is the following: After the Chrome update, new Chrome's password auto fill engine detected password field on the form, and as user/password are remembered site wise, it tried to find closest input field and he put an "username" in it, neat isn't it? 
Actually it is terrible, first/nearest input filed is the Telerik's date-time control, now inside date-time control thanks to Chrome Auto Fill there was client's "username". (very good reason for screaming ...)

And HTML looks like this:

<form autocomplete=off >
<input type="text" name="widget_124" id="widget_124" autocomplete=off />
<input type="password" id="Temporary_Code" name="Temporary_Code" />

Now questions are :
Why would you override autocomplete=off behaviour ?
Why finding nearest input field when name does not even remotely has anything to do with the terms as "user","name","email" ?

So before I start shouting at the developers who build this functionality and start calling them by names of not so intelligent single cell organisms, let me try to answer on these why and let me give you simple solution to this problem.

So what are the requirements:
1. On one side there are number of users, who would like for auto fill to be very clever.
2. On the other side there are developers/designers who know what user should or should not fill automatically.

Now there is an issue, however you try to resolve this, regardless how smart and complex auto fill logic, every time you will end up with one side unsatisfied with your solution, regardless how much you think you are clever, you will end up one side thinking of you as very stupid Chrome developer.

Is there a solution for this, yes and there is and it is very simple.

!!! Proposed Solution:
1. Make "autocomplete=off" functional, if someone has put it in code behind probably there is a good reason for it. 
2. In the context menu put an option "Force Autofill", in that way people who want to have blessings of you super-mighty-very-clever-algorithm ... will have it with two extra clicks.

In this way with the bit of compromise you will have both sides satisfied.

p.s.Chrome Version 36.

Chrome dev's ignorance is simply amazing. Should have rolled back this "feature" long time ago and publicly apologize for putting some so raw in the production in the first place. 

Comment 32 by, Jul 29 2014

Suggestion: If credentials are originally saved on a form with autofill allowed by the webmaster, do not use those credentials on forms where autofill is disabled. Credentials saved on forms with autofill disabled can be used anywhere.

This allows webmasters to differentiate between forms where passwords should be supplied, and forms where they shouldn't, and it still allows users to store passwords whenever they wish.
We've also problems with autofill function from chrome. We've a login form with username and password. When users chooses to save his password, on our payment form, the CVC input is filled with password (I guess because of type=password) and the input field next before this guessed password field is filled with username (even it's the last digit input from credit card).

really annoying - is there anything we can do preventing this?
btw, Chrome 36.0.1985.125 m

Comment 35 by, Jul 29 2014

#32: I'm not sure that gets us anything, as it means that all you have to do to get the old autocomplete='off' functionality is put an input with type=password *somewhere* on your page. And that would be even more confusing, if Chrome started offering to save passwords... but it stored some other field you weren't expecting.

Obviously, we're still working on simply making our confirmation field detection better, but something we're considering is instead of filling in password fields by default, Chrome could just highlight the field in yellow and wait for the user to click on the field to select the account/username they want.

It seems like this might, in practice, address many of your concerns (it would only fill if the user chose to fill in that field). What do you think? Any suggestions regarding this? Notably, it also would have various security benefits (namely around mass XSS across many sites)
#35 I like the idea, I just hate when the yellow looks off from my site. However, users do know the yellow means auto fill. What about some kind of key icon or something.
#35: The highlight may break some company color identity or even will not be visible depending on the background color. But indeed it's the best workaround available so far...

Comment 38 by, Jul 29 2014

#35 Thanks for answering here.

This seems a great idea. It solves the problem we have.
Of course, better login form detection would help, but it is way out of the scope of this issue.

I suppose this autofill-on-demand feature will be activated only when there is an autocomplete="off" attribute on either the text or possword input field ?
And that in other cases, autofill will behave as before ?

Comment 39 by, Jul 29 2014

The yellow already exists; it's the standard password manager autofill color that's currently filled when the password is filled. Unfortunately, a key icon or something like that is out of the question. I don't know the history, but basically Chrome has a policy of not adding icons or stuff like that to the page.

I think something we should keep in mind here is that *everything* we're discussing is a user choice. The user chooses whether or not to use the password manager, so if they don't like the color scheme, the filling... whatever... they don't have to use the password manager (either for the page or overall).

Comment 40 by, Jul 29 2014

Whoops, comments crossed so I didn't see #38 when I posted, sorry :-)

To #38, if we do this, we haven't decided how it would work. I suspect we'd do it *all* the time because of the security benefits (which is where the idea originally came from, although this thread has gotten me more excited about it). Suggestions certainly welcome, though!
#35 I like your idea, but like #36 and #37 I don't want my form fields yellow ;) Safari on OS X does a very similar behaviour and it highlights only autofilled input elements afterwards. I think that's reasonable as users need to be notified that some fields are filled in automatically.
FWIW, there is a bug on file to allow websites to customize the yellow color: bug 46543.  Help wanted :)

Having the user choose to fill the user / password - rather than forcibly fill in the value - is an excellent way to go.

Any situation that makes sites embed hidden fields in order to work around forms being incorrectly filled is a big problem.

We've run into this where we have account maintenance pages that admins use (e.g. administering other users accounts) are getting autofilled with the saved login details, which is wrong.

A couple of thoughts:

1) It may not be a problem to autofill fields on a form that has not requested autocomplete="off", as long as it respects the request when present and only offers an option to fill the field if the user selects it.

2) The password manager could store paths as well as domains - and possibly a fingerprint of the form. Anything that can be used to direct the password manager to only autofill forms where it knows the form is an appropriate target, and only offer the option to fill it if it merely detects that it might be a candidate.

Comment 44 by, Jul 29 2014

Agreed that would work in terms usability, but it would lose pretty much
all the security benefits (since most pages wouldn't use autocomplete='off'
anyway, so mass XSS would still be useful).

I believe it already does store paths, but it tries to make good guesses
about other pages that should have the password filled. As made clear
earlier, though, it's certainly not perfect :-)

Comment 45 by, Jul 30 2014

Anything is better than automatically fill the password, we have a worldwide used software and users start to open security issues, saying that our system is showing their password where shouldn't show. It's not acceptable make hacks on the entire system because of this feature.

Why don't change this autofill feature to something like other browsers does? If you type the first letter of the username then autofill the password? 

I really expected the behaviour of this feature change ASAP. It's really annoying!


Comment 46 by, Jul 30 2014

Partially answering the second paragraph of #38 and maybe some other concerns people brought up here -- since  issue 375333 , Chrome version 38+ understands the other autocomplete attributes: current-password, new-password and username. It can be helpful in hinting Chrome about what the current form it sees is, and might avoid some of the mis-filling issues (although not all of them).
(since this bug still needs feedback, here's some)

This is github's packagist webhook configuration page. You need to enter your packagist username (if it's not the same as your github username) and your packagist api token. Chrome autofills your github username and password, even if the fields already have values!
In fact, Github remembers your packagist username and API token once you set up a packagist hook in one of your repositories, and then pre-fills the fields when you want to do that in other repositories.

None of the new attributes help here, and there isn't a second password field to give chrome a hint that this isn't a regular login page. The only thing that tells it that it shouldn't autofill is, not surprisingly, the autocomplete=off attribute.
42.4 KB View Download
I have most comments and topics regarding this issue and have come up with a solution:

1. auto-fill password/username according to the URL (IE 11 have this behavior - OH MY GOD IE IS BETTER THAN CHROME?)
2. If the field has an ID, auto-fill according to the field ID (which is expected to be only field in the page)

It solves all the issues:
1. If bad designer uses autocomplete="off" it will force auto-fill, but in a more intelligent manner.
2. If website have 2 login forms in the same domain it will autocomplete with the correct data in each one of them according to their page.
3. If website doesnt have id in the fields then it will fallback to the old crap algorythm, but websites at least have a semanthic way to solve this instead of relying into hacks.
4. There is no need for "yellow" highlight disrupting the site design, as suggested above.

The correct behavior would be to comply with the spec, but chromium team are refusing to do so using weak arguments.

Have I missed anything with my suggestions?
Sem título.jpg
36.3 KB View Download

I have *read* most comments and topics regarding this issue...
Do we still need more feedback about this bug?
It's pretty clear, I can add more data if needed.
The solutions above Post 48 and 30 seem to be headed in a good direction.
Is anyone with some fixing power listening?

###      WORKAROUND TO FIX THIS BUG      ###

Just put it after your <form> element (inside).
Exactly like it, just copy and paste!

    <input type="text" style="display: none;" />
    <input type="password" style="display: none;" />

It'll fill "invisibly" with your credentials, 
without break your form.


Comment 52 by, Aug 4 2014

We are listening and appreciate the feedback. As stated in many of the previous comments, we have a number of reasons for not implementing this in as straightforward a manner as comments #30 and #48 suggest, but we certainly on working on improvements.
Thanks for the update jww. It's good to know that you are taking this issue seriously.
I just wanted to ensure that you are not just considering the case of having multiple password fields, but also the case where password fields are legitimately used for purposes other than just logging in.

In our application (Moodle -, there are many cases where we make use of password fields in the UI and where this issue is affecting end users in a frustrating fashion.
In one case, whenever a user edits details for a course, a username and password are filled into our idnumber and guest access fields. In another case, whenever an administrator creates a new user the fields are filled in with their own credentials, and when editing their own profile the change password field is also filled.

Thanks in advance and looking forward to the fix,

Andrew #52 I have spent half of the page explaining the issue and proposing solution, and other people as well. Instead of saying vaguely "we have number of reasons" can you please list some of these reasons, the most important ones?

I have a feeling that 1st and only is probably "because we do not want to do it, and you can ***** !"  :)

Comment 55 by, Aug 7 2014

My apologies, I certainly didn't mean to be vague about it. The reasons are:

(1) As described on other threads (for example!topic/chromium-dev/zhhj7hCip5c and!topic/security-dev/wYGThW5WRrE) we will continue to ignore autocomplete='off' for those reasons.

(2) We do partially base autofill on the URL and path, so we can't "starting doing that" as #48 suggests, but we will continue to improve our heuristics.

(3) A highlight field is inevitable, and is effectively a user's choice. Most password managers have some variant of this, whether it be highlighting the field or placing an icon in the field. Given that it is a user's choice to use the password manager in the first place (and to 'save' for a specific site), that takes priority over site design.

(4) We can greatly improve our confirmation field detection in other ways, which we're working on. Some of the suggestions on this bug will probably be very helpful, although I'm not working on that directly.

Please keep suggestions coming and help us understand how we can help detect fields correctly.

Comment 56 by, Aug 8 2014

I a bit annoyed that all the fuss around this issue will slow the fixing of the core problem.

There are some forms that closely or remotely resemble to login forms.
And there are administrators that do think filling that form automatically, whatever their reason, is a bad idea.

So, basically, chromium wants autofill, and the admin does not.
In this configuration, it would be better to take a conservative approach, and provide a way for the user to decide.
Ignoring the autocomplete flag set purposefully by the admin is some kind of a break of trust.

So yes, improving login form detection is great, but I am convinced that such a detection algorithm cannot be perfect, and that sometimes the admin does know better.
In such cases, why not give him the benefit of the doubt.

You have no idea how many clients ended up with a broken config because of this.
This is even a security threat as the *admin password* ends up filled in random device provisioning pincodes. These pincodes are often transmitted in *simple text form over the network* !
Our application is deployed on the client premisses, we cannot just update the code on the website and see the problem disappear. We need to release a new version, that goes through QA, and then requires approval from the client. All this takes time.

I am trying not to get too excited, but it seems to me that nitpicking about whether chromium should or not detect one, two three password fields in a row, or use pink instead of yellow for the background, completely misses the point.

The damage being done, maybe rolling back to the previous behaviour is not a good idea, but I fear the point at which chromium will be smart enough to work around the hidden input fields trick, and will therefore break the whole application again.
I hope I made it obvious that discarding the autocomplete flag was a too bold move for us, and that there will be no more such nightmares.

I think it's a false dichotomy to frame the argument as  being for or against password managers.  I agree with the chromium team's position that  password managers improve security even when overriding author preferences, but that's not the point. The problem  is that Chromium's *implementation* of this behavior is so poor that the following things are happening:
- users are inadvertently disclosing their email/username in form fields that are not email/username fields.
- users are inadvertently disclosing their *password* in form fields that are not necessarily meant to contain the user's password.

In lieu of these facts, it feels like a net-loss for user security.   I don't doubt that chromium team is improving the detection logic,  but given the fallout we're seeing is it an option to rollback this change until the functionality is improved?

Comment 58 Deleted

"As described on other threads (for example!topic/chromium-dev/zhhj7hCip5c and!topic/security-dev/wYGThW5WRrE) we will continue to ignore autocomplete='off' for those reasons."

I have read all thread before posting, and #48 still stands.

"but something we're considering is instead of filling in password fields by default, Chrome could just highlight the field in yellow and wait for the user to click on the field to select the account/username they want."

That is something that should be done to remediate the most problematic issues if the costs outweight the benefits, but not to solve it completely.
If one have a registration form as I demonstrated in #48, it will still auto-fill the e-mail and password when the user starts repeating the e-mail. That is a unexpected browser behavior, but I can live with that. For now.

Comment 60 by Deleted ...@, Aug 13 2014

I work on some software ( which includes password inputs that should never contain user account credentials. For example, we have interfaces which let administrators configure credentials for connecting to LDAP, or credentials for connecting to external systems with HTTP Basic Auth.

Our users are reporting that their personal account credentials are autofilled in these forms, which they find undesirable and confusing ( The only way we've come up with to prevent this is similar to #51 (add invisible password inputs to the form body), which implies user credentials are silently and invisibly autofilled into a form and possibly submitted over the wire (or potentially serialized with Javascript, etc).

Although I fully sympathize with the intent of this change, if the net result of this change is that sites replace autocomplete="off" with invisible autofilling password inputs that users can not see and which are potentially submitted or serialized, I worry it makes the web less secure without resolving the root problem.

Careless implementors who were previously using autocomplete="off" will presumably just add hidden inputs to their forms instead (and there is already a significant amount of advice suggesting this behavior around the web, both in this thread and on sites like StackOverflow). Making "invisible hidden password input" the new "autocomplete=off" seems worse for everyone.

Solutions like #35 (which require more intentional interaction from the user without allowing sites to disable the behavior completely) would be a great fit for our use case. It doesn't even need to go that far: a smaller compromise, like interpreting "autocomplete=off" to just mean "impose a slightly higher user interaction barrier" (e.g., a click) would also be a good fit, and still let our actual login forms autofill aggressively.
Totally agree with #60, the best way to keep the intended behavior of saving login credentials while still respecting the website creator's wishes is to not autofill by default on fields with autocomplete disabled but instead provide some simple method such as only autofilling if the user starts typing the saved email in.

The whole autofill color clashing with site design is another issue completely that does not relate to the main issue here of other forms being autofilled.
I guess we are stalled with ongoing and nice chit chat here in the forum and no solution?

@jasonvperrin: I agree, though it should not be automatically filled if the form has existing input - e.g. the existing values for a user profile page.

Comment 64 by, Sep 2 2014

For the record, I'm working on something similar to what I described in #35. I'll give more details when I have them. In any case, it won't be an instant fix no matter what because we'll need to make sure it doesn't break stuff before we go crazy pushing it to everyone, so no promises on the exact solution. However, if it doesn't work, we'll work on other solutions.

I'm not sure what else I can say other than we definitely care about this problem and are working on it.
@jww For Enterprise you have to allow the designer/developer to opt out from this forced save password functionality. Consumer focused sites might care less about this issue, but even there are gotchas.

Admin changing a password for user - should not save.
Entering one time password (not a login) - should not save.
Entering CCD of a credit card - should not save.

Until then: where can I find a Javascript implementation of a "password" input functionality?
Or just send over ajax and clear the form before Submit happens?

Is there a better way?

Comment 66 by Deleted ...@, Sep 17 2014

Saved passwords are showing in password manager but don't auto-fill at sign in.

Comment 67 by Deleted ...@, Oct 3 2014

Make "autocomplete=off" functional, if someone has put it in code behind probably there is a good reason for it. 

Comment 68 by Deleted ...@, Oct 6 2014

This is totally demented.   The spec clearly says what autocomplete='off' should do so Chrome is way out on a rotten limb.  The placeholders are removed with autocomplete, so how is that not "user hostile"?   What's more, even if I change the name of the form and the name and id of the input fields, it still somehow autocompletes with the same information which is clearly screwed up, a serious security hole and just plain wrong.  It's extremely developer hostile, highly presumptuous, and dysfunctional.

Comment 69 by, Oct 6 2014

I'll leave comment #68 up for the sake of completeness, but please keep the conversation civil. Referring to Chromium's decisions as "way out on a rotten limb," "highly presumptuous," and "dysfunctional" are neither productive nor helpful. Name calling on the bug tracker is much less helpful than providing precise use cases and problems you've run into.
Honestly, while I agree with #69, I'm still in #68's camp. All belligerence aside, this is definitely a broken feature because it breaks specification, negatively harms the user experience, and forced devs to revisit their applications to provide hacks to work around. I really don't find the argument for this behavior to be convincing. I think there are several enhancements that would make this situation workable (ie. the Safari way of doing this) without rolling back the feature completely. 

As a web developer with over 10 years of experience, I'm really appalled by this. Not to be facetious, but what's to stop Chrome from ignoring CSS colors one day and all websites rendering in Black and White? 

At some point you have to trust what the developer coded as long as it's to specification. While autocomplete="off" is annoying on your standard login page, we either need to better detect these cases or let the user take issue with the specific application and file a bug against them. Making decisions on behalf of the user, especially when it breaks convention, is a perilous road. 

Comment 71 by, Oct 9 2014

TBH I'm in 2 minds about this. I like the fact Chrome now remembers my bank passwords. I dislike the fact the it autofills my create user forms, and change password forms. 
It's not just a user experience annoyance, it's a security hole. Chrome will submit your password in insecure forms, and it can end up being stored in plaintext, like in the example in #47.

Comment 73 by, Oct 9 2014

#70: Chrome does not consider this a break in the standards at all, as we've discussed elsewhere. Both the WHATWG and W3C standards refer to the "autocomplete" attribute field as a "hint", and neither states that the user agent "MUST" perform any action. We, of course, discussed this on various public standards forums before implementing.* CSS is an entirely different beast, with entirely different wording, so I don't consider the two cases comparable.

Yes, Chrome should "trust the developer" but Chrome should also *not* allow the developer to override user choice (as per the priority of constituencies, which is a well defined W3C spec**). Every case discussed above of explicit issues are problems with the *password manager itself*, and are not fundamental problems with ignoring autocomplete='off'. We wholeheartedly agree that these issues need to be addressed, and are working on fixing them. We also just believe that the benefits to users vastly outweigh the temporary costs (which, of course, we didn't know were a problem until we ignored autocomplete='off').

* WHATWG autocomplete attribute:
  W3C autocomplete attribute:
** Priority of constituencies:
jww is correct, this is a problem with the passowrd manager.

As a follow up to the feedback in #48:

"1. auto-fill password/username according to the URL"

This do not work if the website internally forwards the request to your view showing the original URL being accessed with the authentication form. No idea how that could be solved in this case, except delegating the task for the browser to somehow internally map specific fields and autocomplete only those, despite the url you are in.
Just to be clear when I say "internally forwards the request to your view", in case one is not familiarized with java concepts:

It means that, when the user access "//" and is not logged in the app, instead of loading the product content, it loads an authentication form or send 401 for Basic authentication. After submit and successsful login, the URL content is properly loaded.
Just to add another use-case where this is absolutely terrible:

Our product lets users password protect their site, and that field can be edited by any team member. So, Chrome is auto-filling in the user's actual password (without them knowing.. it's a password field), and then displaying their actual password to everyone else on the team.
I fully disagree with the point "Chrome should also *not* allow the developer to override user choice".  When you develop a web application you need to be able to control 100% what the user can and cannot do.  Anything else is allow security issues to creep in.

Please trust the developer.  They know better than users.  When you work support lines as well you understand that users change their email addresses and passwords like most people change socks!  The password manager is great for log in forms but only log in forms.

The simple solution would be, as I said, to trust us.  If I apply autocomplete="off" to the form or input, please do not auto fill anything on that form.  It is as simple as that.

My login form won't have this.  I want that to be remembered as it saves me multiple emails with the user!  If my login form has it, there will be a very good reason for that e.g. the system needs to be 100% secure and leaving remembered passwords on the site is dangerous - users have the ability to not think and click the "remember".

Comment 78 by, Nov 1 2014

If it all about user choice, why can I actually choose it?

Yes I chose to remember passwords on the login screen, but I never had the option on other screens. 
I mention a work around and my opinion in general on the meta issue:

Comment 81 by Deleted ...@, Jan 12 2015

This is insane. We have a form that allows a URL and optional username/password to be entered. Now.. I find that chrome has decided to send the current user's password to random servers over the net with this "enhancement", there seems no option but to switch users over the FF. 
We have an application that allow users to send invitations to other users. When the user clicks the invitation email to sign up, they're greeted with a form like this:

Chrome prompts to save the password but uses the *full name* as the value of the username. The only way around this (using hidden password didn't work) is to add a hidden (display:none) textbox with their *username*. Ideally though, we don't want them to save their password on this screen because we'd want them to *type both of them* to be prompted.

Additionally, we have admin pages where users can be manually created and Chrome will prompt to save their password when the user is created. "autocomplete=off" normally fixed this but now it still prompts again. We've had to tell our users that they should just ignore that popup when using Chrome.

Comment 83 by Deleted ...@, Feb 2 2015

Autosaving any input type=password field breaks administrative user management forms where the administrator is able to change password for other users. This is a typical corporate use case. Chrome keeps asking to save the password for every user...
It also breaks forms where the input type=password field is used for anything that is not related to an user login.

Developers *must* be able to disable automatic saving of passwords.
It's funny, it's been more than a year, and everybody who comes here says the same thing: let the web developer control whether the form uses auto populate, but Chrome developers don't care.

Comment 85 by Deleted ...@, Feb 2 2015

You can disable password saving by putting three additional invisible input type=password fields in the form. It seems that the code that tries to guess the password position in the form will always give up in this case.

This is an ugly hack, tho. autocomplete=off should be respected.

Comment 86 by, Feb 2 2015

Hi everyone. Slight update here. We were experimenting with a feature called "Fill on account selection" to address some of these concerns, but for several reasons we can't launch it as-is. If you'd like to test it out, turn on chrome://flags/#enable-fill-on-account-select (I think only available on beta, dev, Canary, and not on stable yet).

The feature would not fill passwords when the a page is loaded, but would instead mark password fields it can fill in yellow and would wait for the user to select a username before filling. However, it was deemed "not obvious" enough what was going on, so if you test it out and have any thoughts, we'd love to hear suggestions on how to make it work better.
Just follow simple HTML syntax rules. Then you don't have to make up new rules that are not universal to all browser. Just stick to the guidelines and make life simple for all. Trust the developer...I don't want yellow boxes on internal forms. Just on the forms I want my to allow my users to auto fill.

Comment 88 by, Feb 2 2015

As mentioned many times earlier in this thread, we will not be reverting to recognizing autocomplete='off' for the password manager, so please keep this thread focused on how we can address the relevant issues in other ways.

And to clear up a major misconception, this is *not* a Chrome only rule. See for Mozilla's bug for doing the same for Firefox.
Then we entirely disagree. I want to take control of all internal forms of my software. I don't like have to manually remove passwords and emails because some browser developer thinks they can do it better. I don't mind autocomplete on login forms, but chrome tries to be smart and autofills similarly named fields when I am creating new users companies accounts you name it. I often write code to ignore password fields when am updating accounts, if they are empty. But chrome fills it in. I don't know how many times I have accidentally changed someone's password. And it is tiresome. I hate having to put in hacks to stop this behaviour as it increases the complexity of the page, and all future developers need to know why.

It just sounds like you are making it more complicated than it should be. Respect the code respect the developer. We do know what is best for our software. The user doesn't.

But I give up. It sounds like you won't listen to the multitude above on this thread. Such open source democracy!!
@jww: Your priorities are wrong. You released a "feature" that breaks a bunch of webpages and even has security implications (accidentally sending your password somewhere insecure), but months later you don't want to release the fix because it's "not obvious enough".
You should release the fix now, and then you can focus on improving discoverability and usability.

Btw, Firefox does not autofill forms when it detects autocomplete=off, only when you select a username from the autocomplete dropdown in the username field, so it's not doing the same.
The autocomplete="off" functionality of HTML is probably the most elegant solution to the problem, but it doesn't work in Chrome. So what's the point in W3C defining standards, and then ignoring them? It sounds like something Microsoft would do with Internet Explorer.

"The "off" keyword indicates either that the control's input data is particularly sensitive[...]"

When it comes to online banking, this poses a really big problem. Or, in my case, NHS login credentials.
Here are two examples where turning autocomplete off would be useful:

- Registration forms.
- Password changing (As part of a reset procedure).

There are tonnes of situations where turning autocomplete off would be useful however I've only ran into the two above recently hence why I mentioned them.

Ignoring autocomplete attributes is a really stupid move. I, in a way, understand the reasoning behind ignoring it all together but really, it's a bad move.

Part of my issue can be fixed by having different forms have different input names however, it will still prompt you to save passwords and that is certainly not the desired result of a registration form, at the very least!
Not having a way to disable autocomplete is making me crazy!! And so are my customers...

We're building a CRM and showing the phone number, email address... of the user doesn't make any sense we you're actually adding a new customer to the CRM.
Worst, for the city/postal code fields, we popup a list of the available cities based on the first characters typed, and the pane is hidden by the autocomplete pane, which show the city of the user... 

You guys really need to do something about this...

Comment 94 by, Mar 3 2015

This bug is for autocomplete='off' for *password* fields only. For more general autofill issues, please file a new bug.

Comment 95 by Deleted ...@, Mar 11 2015

This bug makes it very hard to use Chrome as an administrator of a learning management system, incidentally. Read the title correctly. This bug address a very serious security issue and cause more problem it solve any. There's actually very little you can do for that at the moment. In our case, we remove Chrome from every administrator's computer. It's unfortunate, but this kind of bug is actually making a great marketing campaign for competitor. If you read the previous comment, some people have managed to create fake input that receive this autocomplete. Maybe for your solution it might be viable.

Comment 97 by, Mar 11 2015

You can also just disable the password manager on your administrator's computer (Settings -> Passwords and Forms) if you find that this is blocking your use of Chrome. Then Chrome will not offer to remember or fill passwords.

#96: Yes, it is about passwords. Please read the content of the bug.

Comment 98 by, Mar 11 2015

And just to clarify further, it's not that I don't believe there's an issue with autocomplete, but we try to keep bugs separate for triage/tracking purposes, otherwise a single bug gets overloaded with too many things to take care of (especially one as long as this). Thus, I'm just requesting that if you genuinely believe there is a similar bug, but not with password fields, it would be extraordinarily helpful to file a new bug.
The Chromium team need to allow website developers to have the ability to disable autofill on certain fields. The autofill wreaks havok on angular / JavaScript meant to trigger on form input fields. 

Comment 100 by, Mar 16 2015

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.

Comment 101 by Deleted ...@, Mar 17 2015

seriously, i cant understund whats going on here. isnt it just that simple? do not touch anything when autocomplete is set to off? red traffic light says dont walk. hell no lets invent – walk!!! and btw david reported autocomplete=off isnt working on forms, not just only on password inputs.
I have filed  issue 468153  for non-password fields. Very simple repro is available at

Comment 103 by, Mar 18 2015

Awesome! Thanks for filing it!
If autocomplete="off" is to be ignored, chrome should provide a non-password field which has the same visual effect as the password fields for the purposes of providing protected data such as SSNs or other non-password protected data. 

I suggest something like:
<input type="protected">
Which would look and act as a password field but not provide password autofilling capabilities.
This last post is a very good idea which should be across all browsers.  Chrome cannot be the one to implement it only though as we get back to hacks and nonsense that we are trying to avoid, but just implementing autocomplete as we need it to be!
 Issue 413856  has been merged into this issue.
This is madness. We have clients screaming at us from all angles. This is costing billions to fix on every website across the entire world!

The rationale for this is completely off the deep end. You've made it end user's choice, but thereby also the end user's *responsibility*, to decide whether auto-complete is safe or secure on, say, e-commerce and internet banking sites. And you really think most end users are more qualified to make such decisions that web developers, banks and store owners?

Has everyone at Google lost their minds?
The idea in #104 isn't a good idea, it's just a more convoluted way of disabling autocomplete on passwords. Web developers will use it for passwords when they want autocomplete off on passwords, then browser makers will be in exactly the same boat they were in when they decided to disable autocomplete="off" on password fields.  A better idea using the existing HTML5 spec would be to respect autocomplete="off" if it's explicitly assigned to an input element. They could address their original concern by ignoring it for password fields when it's on the form if they want, as that's a little less explicit. 

Comment 109 by, Apr 12 2015

Labels: Restrict-AddIssueComment-EditIssue
Unfortunately, there have been a large number of comments on this bug with name calling, so I'm going to restrict this bug to Chromium project members only. I apologize to those of you who have been providing constructive and helpful criticism.
Labels: -Needs-Feedback
Status: Archived (was: Assigned)
For making Chrome understand that a password field is meant for resetting / entering new passwords, use autocomplete="new-passwords" [1].
The fill-on-account-select behaviour mentioned in #35 is still in the works, but not completed yet.
The autofill team is collecting valid use-cases for autocomplete=off (passwords or non-passwords) in bug 587466.

This bug itself is unlikely to result in anything productive any more, so with the info given above I'm closing it.

Showing comments 12 - 111 of 111 Older

Sign in to add a comment