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 74 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 1854: The username and password remember option fill up non login fields.

Reported by, Sep 8 2008

Issue description

Product Version      : <see about:version>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3:OK
    Firefox 3:OK
         IE 7:OK

What steps will reproduce the problem?
1. Open ACP of PHPBB3 in the "Forum" table
2. Edit a forum

What is the expected result?
You'll be able to view the actual setting of this forum. 

What happens instead?
The Password and the username used to login to the forum are automatically 
entered in the "Forum Image" and the "Forum Password" fields, even if these 
fields were empty before.

Please provide any additional information below. Attach a screenshot if 
106 KB View Download

Comment 1 by Deleted ...@, Sep 24 2008

I think the cause of this incident is identical to what I've run into.

1) Login
2) When Chrome asks if it should remember your password, choose to do so
3) Select "My Profile" from javaranch links
4!!!) The "Publicly Displayed Name:" field is replaced by what Chrome remembered as 
the login name.
The element for the login page is:
<INPUT TYPE="TEXT" NAME="username" SIZE="30" MAXLENGTH="40"> 

The element for the Publicly Displayed Name is:
<INPUT TYPE="TEXT" NAME="public_name" value="Marc Peabody" SIZE="35" MAXLENGTH="35">

As the attached image shows, Chrome forces "marcpeabody" to replace "Marc Peabody" as 
the public_name.

The names of the elements do not match. At first I thought maybe Chrome assumes that 
any element with "name" somewhere in the name must be a username to fill out. Now I'm 
thinking that since the login page and edit profile page both use the same base URL 
( Chrome is simply forcing the 
username password into the first two text elements on the page. This is incredibly 
undesirable for forum software that uses the same base URL for multiple features in 
addition to the login screen.
32.5 KB View Download

Comment 2 by, Sep 30 2008

Labels: -area-unknown Area-Misc

Comment 3 by, Oct 8 2008

It's not a minor problem. We have a CMS with (admin)user management pages. If one 
wants to edit a user page there in Chrome, the page comes up with the full name of 
the edited user overwritten with the managing user login name, and the password with 
its password (with yellow background). Even when these fields has a default value 
given e.g. with value="John Doe" in its input tag!!! Also one can't get the original 
name/pwd of the managed user, and the submitted form contains the manging user's 
username (as full name) and password instead of the managed user's (original) data 
(causing the user can't log in, and can't be seen by its name anymore)!!!

I think a minimal solution could be of this issue that when loading a page where 
Chrome thinks, there are login fields to be fill in with saved data, it should first 
check if the fields have no default value (given value="<some data>"), and fill in 
just in that case (although that could eliminate the automatic fill in cases e.g. the 
default value is "Enter login name here" etc.). A best solution would be (at least in 
that cases, when there's a default value) a sign in that fields what Chrome 
identifies as a login filed, and focusing on that field Chrome provides a selectable 
list of available saved logins to be used.

(And lets think of a situation where there are 2 different sites in the same domain 
[the paths are different; Chrome saves logins a per domain basis – another problem 
here]. The problem could be more weird in that case...)

Comment 4 by, Nov 11 2008

Taking these to triage.

Comment 5 by, Nov 14 2008

Labels: -Area-Misc Area-WebKit
Need to validate that this still happens in the nightly builds.

Comment 6 by, Nov 17 2008

Re: Comment #5 by jon:
Confirmed. Checked against the latest nightly build:
Chromium (Developer Build 5556)
The same issue here with all of the (side-)effects mentioned by myself in Comment #3. 
(I.e., if Chrome/Chromium saves a username from a "login" named input for a 
domain/path, every "name" and "password" named fields (with types "text" and 
"password") of everey forms on the same domain (even when it's a different system 
with a different initial path, even with default filled values) will be filled with 
the first saved "login"/"password" pair by Chrome automatically.)

On the side, another anomaly appeared here with this 5556 build (in comparison with 
the Chrome version; at least I couldn't reproduce it with this version): 
whenever Chrome has one (and only one) username-password pair saved for a 
domain/path, and I want to log in with the same username but another (otherwise 
correct) password into a system located at the same domain but with a fully different 
path, Chromium has crashed.

Comment 7 by, Nov 19 2008

I just tested this again with (Developer Build 5673).  Behaviour is 
consistent with previous versions.

Based on the different place in the page it appears, I would say that what is 
happening is the browser is finding the first password field on the page and then 
filling that with the password, and whatever is above it with the username.

On a phpbb forum profile page, this results in emailaddress being filled with the 
user name (user names are not changeable and so are just displayed as text, not as an 
input field.)

On a custom registration page which has the password almost at the bottom, it is 
filling the username in for the cellphone field - this is the field above the 
password field, which is what led me to believe it is searching for the password 
field and then just assuming the field above is the username (on a login page this 
should be true - on a registration or profile page it often will not be.)

since fields can be inconsistently named (e.g. in this case on registration the field 
which will become username is called emailaddress, but then on the login form it is 
called username) I am sure a fix which retains the auto fill functionality is 
difficult.  Possibly it requires a standard to which sites need to conform (username 
called username everywhere even if it is an email address as well) - this would also 
require the browser to check for a field called username and one called password, and 
then it could guess if it doesn't find both.

It wouldn't be perfect, and won't help at all on sites I can't change and which the 
designers won't change (the custom reg page is on a site I built and I can change, 
phpbb I can't) but it would be a little better than the current situation.

Comment 8 by, Nov 20 2008

Comment 9 by, Dec 12 2008

I saw some news about Chrome not being beta anymore, so I'm a bit disappointed that 
this hasn't been fixed yet. This is the most irritating bug that I repeatedly 
encounter on several sites.

Example: site

login field is:
<input type="text" name="username" value="" class="textfieldnorm" tabindex=1 />

the field on device settings:
<input type="text" name="ssid" value="Europa">

The login name overwrites the value "Europa"... also as you see one of the WLAN-
password fields gets filled.

Attached few images for you. I use Google Chrome, not Chromium. The version is
67.6 KB View Download
121 KB View Download

Comment 10 by, Dec 16 2008

Labels: -Pri-2 -Area-WebKit Pri-1 Area-BrowserUI Mstone-1.1
Status: Available

Comment 11 by, Jan 2 2009

Comment 12 by, Jan 2 2009

The big problem I see discussed here is overwriting default values, which we 
definitely need to fix. However, the only time Chromium fills/remembers on a "per 
domain basis" (brought up in comment #3) is the first time the user visits the second 
login form on the same domain as where an existing login is saved. Chromium looks for 
a "best match", which in this case will be the one with the same origin (also the 
minimum match for this form). From then on, if you save new credentials it will 
remember the two domains individually, which helps (for example) with hosted Google 
apps like GMail, allowing you to have different credentials at and  Note that if the action 
URI differs on the two forms, Chromium won't do this until the user fully types in 
the username and focuses the password field).

And the strategy for finding a username/password pair on a page is in fact to look 
for a password field and assume the preceding text element is the username. I don't 
think this is bad, as long as we make sure to not overwrite text already provided by 
the page. It is simple, and it's the most helpful when it needs to be. As for "false 
positives", the worst case is where we fill a username into a blank "Given Name:" 
field, but once the user focuses the field and Chromium selects the text I don't 
think the user experience is very different? I'm open to simple alternatives, but I'm 
not convinced the "opportunity cost" we give up in the bad cases (where a password 
field follows an empty given-name field) warrants anything too complicated.

Comment 13 Deleted

Comment 14 by, Jan 2 2009

Is there a real reason not to do it like for example Opera does it?
There are few things in Operas password remembering functionality that are super:
- It allows you to save the username/password combination for the exact URL only.
- It saves other data on the login form too, like "Remember me" on MediaWiki or 
"Remember me on this computer." on Google account login page (for example on GMail).
- It allows saving only password field where there is no username field, this is 
useful if the site uses some kind of "verification code" for extra security etc.
- It allows multiple account information on one login field. Useful if you have more 
than one credential on one page (see, not all sites do like Google and use different 
pages like and, and Chromium 
shouldn't be the one saying that site administrators should add such functionality). 
Also this is clearly indicated by giving and selection box asking which credential 
you want to use this time.
- It DOES NOT overwrite or fill anything automatically. It creates an indication with 
yellow color to those fields/checkboxes/other form elements that can be filled with 
the password remembering functionality. Not filling anything automatically has the 
advantage of not doing ANY irritating activity on ANY sites. Saying that people can 
not and will not press a key combination like Ctrl+Enter or click a button (that 
could be automatically located next to the login field if you want to make things 
"easier") is an harsh underestimation.

I appreciate the fact that Chromium has done many things differently and to be fair, 
right. But some things have already been developed by others so that they work 
correctly. In those cases the functionalities should be imitated. Just a least think 
about it, especially the not overwriting/filling anything by default part.

Comment 15 by, Jan 2 2009

"And the strategy for finding a username/password pair on a page is in fact to look
for a password field and assume the preceding text element is the username. I don't
think this is bad, as long as we make sure to not overwrite text already provided by
the page. It is simple, and it's the most helpful when it needs to be. As for "false
positives", the worst case is where we fill a username into a blank "Given Name:"
field, but once the user focuses the field and Chromium selects the text I don't
think the user experience is very different? I'm open to simple alternatives, but I'm
not convinced the "opportunity cost" we give up in the bad cases (where a password
field follows an empty given-name field) warrants anything too complicated."

The user experience is very different when I have to delete auto-filled information in order to be able to use a form (in my case a profile editing 

The worst case for me is in fact that Chromium is filling in information that must be cleared in order to proceed with a form, when with other 
browsers I need enter nothing and delete nothing and can bypass those fields entirely.  Both the "username" which isn't a username, and the 
password field need to be cleared, as these fields must only be used on these profile pages if you want to change your password, not just for 
editing the form.  If I do not clear them then nothing I submit is saved because these fields are filled in incorrectly.

Although I will use these pages much less often than I will want to log in to sites, it is annoying enough to bug me every time I do want to edit a 
profile page which behaves like this.

What about remembering the exact username/password field name combination for that domain's login page and only filling in when this exact 
combination is found, rather than assuming that the field prior to the password field is a user name field?  It seems pretty clear that there are a 
fair number of situations in which this is *not* the case.  Any site which has different login pages with different field names for the 
username/password fields is badly designed and so in that case Chromium could not be blamed if it only fills in on the one form until it has 
references saved for both, or always only the last combination used on that domain.  Is this really that complex (I ask sincerely since I don't 
know if it is complex or not)?  This way you can avoid filling in non-relevant fields.  I don't know if this will properly fix everyone's problems 
but I suspect it has a good chance.

As it stands, I consider Chromium's password fill-in feature to be significantly inferior to IE, Firefox and Opera (I don't know if Safari works 
the same as Chromium?) because of this problem - previously I thought it superior, until I encountered this issue.  I would much rather have to 
actively ask for the information to be filled in.  I particularly like the way Opera works with a key command which auto-fills the fields, this is 
my preferred method of the 3 used by the different browsers, but I would settle for IE/FF style if that is significantly easier.

Comment 16 by, Jan 9 2009

Labels: -Pri-1 -Mstone-1.1 Pri-2 Mstone-2.0
@kuuranne, thank you for your comments. I'll respond to your points individually; if 
you or others are unsatisfied please open a bug for the particular issue so we can 
keep this bug focused towards it's title, thanks!
1- We chose not to match exact URL only (as I explained above and in a Chromium Blog 
posting) as this breaks usability of many sites [often in ways you don't realize 
until you try it out (which believe me, we have done)].
2- You can file a feature request for this, it seems like a good idea.
3- Same as 2, though it would require a bit more work as the username is used as a 
key in several places in code.
4- We currently support this. If you save multiple logins on one field, you will get 
inline autocomplete for each of them as you type in the username. I believe the 
"selection box"/ drop down is currently in development.
5-As I stated in comment 12, we agree this is a problem. I am about to submit a patch 
to make sure we don't overwrite prefilled values. See  issue 6197 .

I am dropping the priority of this to Normal as, while I/we should consider some of 
the points in comment #15 and the original intent of the bug, I don't feel the 
relatively small number of page views it affects adversely is blocking any upcoming 
milestone release, especially with  issue 6197  about to be fixed. I'll reply shortly 
to #15 specifically.

Comment 17 by Deleted ...@, Feb 13 2009

Is the problem fixed with login/passwd field population to other login screens used
in the same domain?

I have a situation where I have admin login and a user login in the same domain name
at different places. Even though i prefilled the fields with default values i still
see chrome browser population of existing saved login/passwd values.

I see there is a patch as per the comment#16 for this bug but I don't see it working.
Am I missing something?? is the patch part of latest version of chrome browser or is
it something that we need to implement at our end?
960 KB Download

Comment 18 by, Mar 2 2009

Are we going to see anything regarding the issue from comment 15?  Whilst 
administering phpbb forums it inserts my username and password into any user that I 
am editing into the "Confirm email address" and "New Password" boxes of the form that 
I have to manually delete.

Comment 19 by, Mar 11 2009

Using I just noticed this while editing users in my local Bugzilla 
installation here at work. I had made Chrome my default browser, but for me this is a  
stopper. I'm switching back to Firefox until this is fixed.

Comment 20 by, Mar 11 2009

Status: Assigned

Comment 21 by, Mar 17 2009

Labels: -Mstone-2.0 Mstone-2.1

Comment 22 Deleted

Comment 23 by, May 19 2009

Labels: -Mstone-2.1 Mstone-2.2

Comment 24 by, Jun 3 2009

This issue has been affecting our software as well. I have to agree with others about
this being a major bug. This can cause irreversible affects upon saving another users
profile from our administrator control panels.

While we can overcome this with browser hacks, none of them are the correct solution
to this issue. The browser itself needs to be fixed rather than thousands of scripts
being updated to work around this issue.

Comment 25 by, Jun 3 2009

I sincerely can not believe that this bug hasn't been fixed yet, as it concerns many 
major portal/forum/wiki/cms applications. has been fixed though, so 
props for that...

Comment 26 by, Jun 4 2009

Re: Comment 25 by kuuranne and Comment 16 by tim: There's still a problem with the fix 
of the  issue 6197  (see ): 
however it don't fill up login field with prefilled values anymore, but it still fills 
up the corresponding password field, if that's not prefilled (resulting an unmatching 
username/password value).

Comment 27 by, Jun 15 2009

Labels: Mstone-3
Status: Untriaged
Moving to mstone 3 from an older milestone.  Need to triage.

Comment 28 by, Jun 16 2009

Labels: -Mstone-3 Mstone-X
Status: Available

Comment 29 by, Sep 22 2009

It's related to  Issue 11167 

Comment 30 by Deleted ...@, Oct 8 2009

I would think the most practical way to solve this is when chrome saves a un/pw for a
site notes what page it saved it for and only auto-populates the the un/pw field on
that same page.

I am running into this bug constantly with Drupal sites that have people requesting
to become a user. When you go to approve the user it auto fills in my password for
the site since the field is blank and requires me to clear the field out each time as
you can see in the screen shot I attached.
398 KB View Download

Comment 31 by, Oct 8 2009


(French English translation via google) 
I must say that this bug also disability 
Phpbb2 forum on the membership profile as it has already been said above fields 
and user 
password are already filled 
Even in the config forum just stick it in the field SMTP username and SMTP 

For Christmas 2009 please fix that bug us! 

Thank you
bug chrome 2.JPG
121 KB View Download

Comment 32 by, Oct 9 2009

It disability all website where is login and password (i.e. Drupal, Redmine, etc.), 
even for hidden fields which shouldn't be filled.
Here is some explanation how logically it should work in my opinion:

Comment 33 by, Dec 9 2009

Another anomaly regarding Chrome's Password Manager reported as  issue 29352  (Chrome 
crashes while trying to display a form with certain constellations of input fields fillable by PM).

Comment 34 by, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label

Comment 35 by, Jan 18 2010

 Issue 10027  has been merged into this issue.

Comment 36 by, Feb 17 2010

Labels: Area-UI

Comment 37 by, Feb 17 2010

Labels: -Area-UI-Features

Comment 38 by, May 6 2010

This bug affects Joomla installations too.

- The administrator login form has a username and password field, with names 'username' and 
- The register form on the front end has fields with names 'username', 'email' and 'password'. 
However, Chrome fills the username into the email field.

Comment 39 by, Jun 23 2010

This bug affects Hudson as well.

My password been set up in LDAP and by submitting the attached form, my credentials has been published for all my colleagues in government organisation and they could access hundreds of different services using my password.

This is very critical issue.
Screenshot-Deploy Production Config [Hudson] - Google Chrome.png
146 KB View Download

Comment 40 by, Jul 1 2010

This is also affecting Hudson for me.  

My saved login password appears with a yellow background in the default value (NON-password!) input field in project config for parameterized builds.  

Loading and saving a project config with no changes then causes my login password to be saved to the project as a default value and thus visible to anyone with permission to build the project.  

This is a major security risk and prevents me from saving my password at all for Hudson installs.

Comment 41 by, Jul 1 2010

Comment 40 re Hudson is with Linux Chrome 6.0.437.3 dev and Hudson ver. 1.336

Comment 42 by, Jul 3 2010

#39: Linux Chrome: 5.0.396.0-dev, Hudson ver. 1.358

Comment 43 by, Aug 11 2010

It's overriding the login details for SVN Repository in Redmine for the project!

Comment 44 by, Jan 21 2011

After 2 and a half year this is still not fixed.

Comment 45 by, Mar 15 2011

This bug also affects our application.  The Add User page's longitude field is being populated with the current users login, and the PIN field with the password.

Comment 46 by, Mar 15 2011

I use Chrome as convinced of the potential and constantly changing, but I am surprised that this very annoying bug is not fixed. Google engineers Please lean on this issue that I'm looking more closely you will find the solution quickly. Forum administrators will tell you a big THANK YOU

Translated with Google Translation

Comment 47 by, Mar 15 2011

Can you add more Cc people to that issue? 2,5 years and only 3 people? It's affecting all people, most of the websites and all operating systems.

Comment 48 by, Mar 15 2011

Abandon all hope, ye who stumble into this bug.

Comment 49 by, Mar 31 2011

Maybe more people should vote on it?

Comment 50 by, Apr 1 2011

A temporary solution is using "Last Pass" extension.

But I also hope Chrome team will fix it up, make Chrome be better and better!

Comment 51 by, Oct 31 2011

Labels: Feature-Autofill

Comment 52 by, Oct 31 2011

Labels: -Mstone-X Feature-Passwords Hotlist-GoodFirstBug

Comment 53 by, Sep 11 2012

I don't know if this issue is still active, but I was having a look at it and put together some tests (attached).

In the test, after submitting a username and password in the login page the browser is redirected to a series of test forms.

Test 1: Two input fields that have no "name" attributes
Test 2: Two input fields that have filled but unrelated "name" attributes
Test 3: Two input fields that have the same "name" attributes as the login page
Test 4: Duplicate of test 3
Test 5: 2 input fields that have the same "name" attributes as the login page and default values.

I ran the tests in different browsers, they behave pretty differently:

Chrome 21.0.1180.89:
  -On second page, fills in every input field pair that has a "name attribute" and no default value (Tests 2, 3, 4)

Firefox 15.0:
  -Seems bugged, on second page fills in all passwords without default values only (Tests 1, 2, 3, 4)

IE 9.0.8112.1642
  -Does not fill in any values in the second page at all. Maybe requires absolute path to be the same for autofill to work.

Safari 6.0
  -On the second page, only fills the first input pair that has a "name" attribute, even if the name does not match the original "names" (Test 2)

Seems like there is no consensus on how to deal with the issue. 

Perhaps the incorrect autofills reported here would be lessened if Chromium only autofilled inputs in subsequent pages if the input "name" attributes matched the "names" of the original input elements from which they were saved.
1.1 KB Download

Comment 54 by, Mar 10 2013

Project Member
Labels: -Feature-Passwords -Area-UI -Feature-Autofill Cr-UI Cr-UI-Browser-Passwords Cr-UI-Browser-Autofill

Comment 55 by Deleted ...@, Mar 19 2013

Strange that this is still open after 5 years. It is STILL happening in current version.

Login form is user name and password.

<input class="span3" type="text" name="strUser">
<input class="span3" type="password" name="strPassword">

My account form is full name, email, and password.

<input id="strUser" class="xlarge" type="text" maxlength="100" name="strUser" value="Administrador do Sistema" />
<input id="strEmail" class="xlarge" type="text" maxlength="150" name="strEmail" value="" />
<input id="strPass" class="large" type="password" maxlength="100" name="strPass" />

If you go to the account form, chrome automatically fills in the password, and overwrites the email (field preceding password) with username.

Attached are screenshots
4.5 KB View Download
16.9 KB View Download

Comment 56 by Deleted ...@, Apr 25 2013

This is happening for our WebForms application, but only started in the last couple of weeks.

We have a page search field and that gets wrongly auto-filled by the remember password feature (with the username), even though there is no corresponding password field on the page. Previously, I have got around this problem by adding the autocomplete="off" attribute on the input field but Chrome recently has started to ignore this entirely.

Comment 57 by, Apr 25 2013

We've also started to experimence this recently.
25 was ok, 26 and 27 was buggy on win7.

Comment 58 by, May 18 2013

Labels: -Hotlist-GoodFirstBug -Cr-UI-Browser-Autofill
This bug sounds like it is the same as  bug 72508 , which was fixed two years ago.  I'm not able to reproduce the issue with the code snippets provided in comment #55 -- Chrome correctly leaves the password unfilled when the saved username doesn't match.  For those of you seeing this issue, please provide a minimal reduced testcase that reproduces this issue.  (The screenshot from comment #55 makes it clear that there's more HTML on the affected page than the snippet shows.)

Comment 59 by, May 21 2013

 Issue 108751  has been merged into this issue.

Comment 60 by, May 24 2013

Based on the code snippet which was provided to comment #53 I'm able to repro it on win7, win8 with v26 with the following steps:

1. run node ( node server.js ), go to localhost:1337/login.html
1. enter any dummy username and password
2. submit the form
3. when asks for to store/save your password, please accept it.
4. go back to loginpage
5. submit again
6. tadaaa, the bug is there, chrome fills out unrelated fields.
567 KB Download

Comment 61 by, Jun 6 2013

Can someone please look at fixing this.

It is essentially blocking people from updating their user profile in our product. And It's been like this since Chrome 26 came out all the way back in March. And it's still there in Chrome 27.

Comment 62 by, Jun 21 2013

Status: WontFix
There are at least three separate issues being discussed here:

(1) Chrome fills <input autocomplete="off"> elements.  This might be a bug.  Filed as  issue 252609 .

(2) Chrome fills <input> elements whose 'name' attributes don't match those of the form from which the data was saved.  This is intentional, as registration forms often use different 'name' attributes than the corresponding login forms, and we want Password Autofill to work in this case.

(3) Chrome overwrites <input value="some prefilled value"> elements.  I am unable to reproduce this issue, and can point to code that should address it.  I think this might have been a live bug at one point, but is now fixed.

I'm going to close out this bug, as it's gotten too unfocused to be actionable.  If you're seeing any issues besides the three I've listed above, please file a new bug.  Feel free to email me the bug number for triaging.

Comment 63 by Deleted ...@, Dec 10 2015

Hi, I am also facing the same issue. May be chrome works in such a way that whenever it finds password field, It fills saved password then and there also checks backword username field and fills username as well. I have a registration form which contains only one password field and username field. Chrome autofills username and password.

Sign in to add a comment