The username and password remember option fill up non login fields.
Reported by tito...@hotmail.com, Sep 8 2008
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 possible.
Sep 24 2008,
I think the cause of this incident is identical to what I've run into. site: http://saloon.javaranch.com 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 (http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi) 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.
Sep 30 2008,
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...)
Nov 11 2008,
Taking these to triage.
Nov 14 2008,
Need to validate that this still happens in the nightly builds.
Nov 17 2008,
Re: Comment #5 by jon: Confirmed. Checked against the latest nightly build: Chromium 0.3.155.0 (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 0.3.154.9 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.
Nov 19 2008,
I just tested this again with 0.3.155.0 (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.
Nov 20 2008,
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: my.wippies.com 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 188.8.131.52
Dec 16 2008,
Jan 2 2009,
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 mail.google.com/a/foocompany and mail.google.com/barcompany. 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.
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 mail.google.com/a/foocompany and mail.google.com/barcompany, 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.
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 form.) 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.
Jan 9 2009,
@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.
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?
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.
Mar 11 2009,
Using 184.108.40.206. 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.
Mar 11 2009,
Mar 17 2009,
May 19 2009,
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.
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. http://code.google.com/p/chromium/issues/detail?id=6197 has been fixed though, so props for that...
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 http://code.google.com/p/chromium/issues/detail?id=6197#c5 ): 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).
Jun 15 2009,
Moving to mstone 3 from an older milestone. Need to triage.
Jun 16 2009,
Sep 22 2009,
It's related to Issue 11167
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.
Oct 8 2009,
Hello (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 password. For Christmas 2009 please fix that bug us! Thank you
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: http://code.google.com/p/chromium/issues/detail?id=11167#c1
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).
Dec 18 2009,
Area-UI-Features label replaces Area-BrowserUI label
Jan 18 2010,
Issue 10027 has been merged into this issue.
Feb 17 2010,
Feb 17 2010,
May 6 2010,
This bug affects Joomla installations too. - The administrator login form has a username and password field, with names 'username' and 'passwd'. - The register form on the front end has fields with names 'username', 'email' and 'password'. However, Chrome fills the username into the email field.
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.
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.
Jul 1 2010,
Comment 40 re Hudson is with Linux Chrome 6.0.437.3 dev and Hudson ver. 1.336
Jul 3 2010,
#39: Linux Chrome: 5.0.396.0-dev, Hudson ver. 1.358
Aug 11 2010,
It's overriding the login details for SVN Repository in Redmine for the project!
Jan 21 2011,
After 2 and a half year this is still not fixed.
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.
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
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.
Mar 15 2011,
Abandon all hope, ye who stumble into this bug.
Mar 31 2011,
Maybe more people should vote on it?
Apr 1 2011,
A temporary solution is using "Last Pass" extension. https://chrome.google.com/webstore/detail/hdokiejnpimakedhajhdlcegeplioahd But I also hope Chrome team will fix it up, make Chrome be better and better!
Oct 31 2011,
Oct 31 2011,
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.
Mar 10 2013,
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="firstname.lastname@example.org" /> <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
Apr 25 2013,
This is happening for our ASP.net 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.
Apr 25 2013,
We've also started to experimence this recently. 25 was ok, 26 and 27 was buggy on win7.
May 18 2013,
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.)
May 21 2013,
Issue 108751 has been merged into this issue.
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.
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.
Jun 21 2013,
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.
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