Closed Bug 258543 Opened 15 years ago Closed 13 years ago
Disabling form autocomplete prevents selecting from multiple saved logins
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040908 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040908 Firefox/0.10 Trying to select a username on a website with multiple logins while form fill is disabled no longer works. The password, however, is still filled when you manually enter the username. This is counterintuitive, as websites with one login stored will still fill in the username automatically. I have tested this with bugzilla, mail.com, gmail.com (when it still allowed saved logins) and a couple of internal sites at my university. JunkieV at http://forums.mozillazine.org/viewtopic.php?p=775099&highlight=#775099 also appears to verify. Reproducible: Always Steps to Reproduce: 1. Disable Form Fill. 2. Visit a site where you have multiple logins stored. 3. Press down or doubleclick on the username form. Actual Results: Nothing Happens. Expected Results: The autocomplete widget drops down listing the multiple login identities. There are couple bugs like this (Bug 220734), but this one showed up after most of these bugs. It may have been caused by Bug 173569 (it regressed around the same time), but I am not sure.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This regressed sometime between 0.9 and 8/19. Sorry I can't do any better, but that is the latest build I can find. Added regression keyword.
I did some more testing (thank you pryan!) and it looks like Bug 173569 is the cause for this. 7/28 works. 7/30 does not. Bug 173569 landed on 7/29. Someone with a better understanding correct me if I am wrong.
I doubt it was bug 173569. You missed these two check-ins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=mozilla%2Ftoolkit&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-07-29+01%3A09&maxdate=2004-07-29+01%3A31&cvsroot=%2Fcvsroot If I were to pick one, I'd say it was the fix for bug 249610.
Thank you Dean, I appologize for the bugspam. Bug 249610 does look like the best bet.
*** Bug 259019 has been marked as a duplicate of this bug. ***
sounds like this is mostly fixed -minus for 1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Chris, where did you see that this is mostly fixed? Re-nominating. If I missed something, minus this again.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
This is not fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040930 Firefox/0.10 (sweelou from a few hours ago).
Aha, so disabling form fill is what was causing this. I've been seeing this with my public library's web interface, which is highly annoying because the 14-digit library card number (=username) is much harder to remember than the password is. I've been having to pull up the list of saved passwords, memorize the number temporarily (since you can't copy-paste it), then type it in the form, and only then does the password get filled in.
bryner, can you have a look? in the worst case, if we need to trade this bug or backing out Bug 249610 which would we choose?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Re the last comment, this bug causes inconvenience, but Bug 249610 is a security concern.
15 years ago
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Holy ****, I noticed this as a bug, but didn't bother reporting it. Whenever I report a bug, it's always a dup, even if it isn't. ;_; Yes, this is still a problem and should be fixed. If you type in the username and tab to the password box, it will autofill the password. Other than that, there is no drop-down box.
Summary: Disabling Form Fill Prevents Selecting Identities On Sites With Multiple Saved Logins → Disabling form autocomplete prevents selecting from multiple saved logins
Updating. Sorry for Bugspam.
OS: Windows XP → All
Hardware: PC → All
Version: 1.0 Branch → Trunk
its an inconvenience, but typing the username prefills the password so its an inconvenience really. Patches welcome, but this isn't a blocker for Deer Park. We should look at it next cycle though.
Severity: major → minor
I think it's a little more serious than what's stated in comment #15. I generally only use the save password feature for non-critical sites that have obnoxiously long login names (eg. 12-digit account numbers). In my particular case, I have several accounts on such a site. I can't easily remember the login name, nor do I really want to type it in everytime. The point here is that I use the save password feature to remember login names/account as well as the passwords themselves. The problem with the form fill is that it's not site specific. I don't know of a way to tell it to save my form information for this site but not others. In particular, I don't want login IDs from other more secure sites saved by form fill.
ultimately, this is still a minor bug, and there are bigger fish to fry. Minusing, will take patch.
Assignee: bryner → nobody
Flags: blocking-firefox2+ → blocking-firefox2-
QA Contact: davidpjames → password.manager
I am willing to try to fix this bug (no promises), but I am not sure where in the code to look. Can anyone point me in the right direction?
(In reply to comment #18) > I am willing to try to fix this bug (no promises), but I am not sure where in > the code to look. Can anyone point me in the right direction? In looking for where to point you to fix the bug, I think I may have found a fix... I'll attach a patch in a minute.
This is similar to the situation in bug 338064. The browser code goes through a lot of trouble to observe the "form history is enabled" pref and toggle "no autocomplete" on content when it is disabled, and since the password manager is just another form of autocomplete, it gets disabled too. Since the form history part of the autocomplete already checks the pref before returning a result, there's no need to disable all of autocomplete just because the form history pref is set to false. I've tested that this doesn't regress 249610, but further testing would of course be appreciated.
Thanks Gavin. I had a hunch that it was similar to the work you had done in bug 338064, but I did not know where to look. I have tested this patch and I have not run into any regressions.
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 2 beta1
Version: Trunk → 2.0 Branch
Renominating now that there is a patch...
Flags: blocking-firefox2- → blocking-firefox2?
Won't block the release for this, but if you get a reviewed patch in and baked on trunk please nominate it for 1.8.1approval in time for beta2.
Flags: blocking-firefox2? → blocking-firefox2-
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Comment on attachment 226097 [details] [diff] [review] patch mconnor, can you review? I'd kind of like to get this into b2, but I guess that's not very likely at this point... :(
Attachment #226097 - Flags: review?(bryner) → review?(mconnor)
FWIW, I have been running this patch for almost two months and I have not come across any regressions.
(In reply to comment #25) > FWIW, I have been running this patch for almost two months and I have not come > across any regressions. Thanks for the testing Jim, that really is quite valuable. I'll push to try to get this patch into Firefox 2.
Comment on attachment 226097 [details] [diff] [review] patch Let's give it a few days on trunk, but I think this is sane and correct.
Attachment #226097 - Flags: review?(mconnor) → review+
Checked in on the trunk. Verification that the problem is fixed in trunk nightly builds would be appreciated. mozilla/browser/base/content/browser.js 1.695
Severity: minor → normal
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: Firefox 2 beta2 → Firefox 2
Whiteboard: [needs approval]
Working on trunk. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060827 Minefield/3.0a1 ID:2006082704 [cairo]
VERIFIED fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060828 Minefield/3.0a1.
Status: RESOLVED → VERIFIED
Comment on attachment 226097 [details] [diff] [review] patch Drivers: see comment 20, comment 25.
Attachment #226097 - Flags: review?
Attachment #226097 - Flags: review? → approval1.8.1?
Comment on attachment 226097 [details] [diff] [review] patch We're a little nervous about making a change like this at this time, and it's not severe enough an issue to warrant the risk; let's leave it fixed on trunk.
Attachment #226097 - Flags: approval1.8.1? → approval1.8.1-
I wish I had known about this sooner. A couple years ago we thought our banking site had disabled password fill on our banking site and that's why it wouldn't fill in anymore. I did notice that the password filled in after hitting tab after filling in our number, but we thought that was cuz the password had been stored previously to the supposed site change. I think there are going to be a lot of users facing this issue thinking it's firefox respecting a site's desire to not autofill, especially when you figure in that my equally oblivious husband is mconnor. If he didn't realize the issue was on firefox' end how are most users supposed to? This patch is needed polish to an already existing feature, which is invaluably important especially as new features are added. There are enough users that notice while x feature is new and shiny w feature is still not working right.
Whiteboard: [needs approval]
Target Milestone: Firefox 2 → Firefox 3 alpha1
Version: 2.0 Branch → Trunk
Please forgive me if I'm messing up, but this is my first post on this forum. I'm running FF2 and seems like this bug is still around. Please look at the following page: https://www1.royalbank.com/cgi-bin/rbaccess/rbunxcgi?F6=1&F7=IB&F21=IB&F22=IB&REQUEST=ClientSignin&LANGUAGE=ENGLISH It doesn't fill the login information (even though I have only one saved login), but when I enter the login id it fills out the correct password.
Yes. the bug has been fixed on the trunk (road to Firefox 3.0)
This has baked on the trunk for a while with no known regressions. Can this be checked in on the 2.0 branch?
Comment on attachment 226097 [details] [diff] [review] patch Approved for 1.8 branch, a=jay for drivers.
Attachment #226097 - Flags: approval126.96.36.199? → approval188.8.131.52+
Whiteboard: [checkin needed (1.8 branch)]
Whiteboard: [checkin needed (1.8 branch)]
Confirmed existence of bug in 184.108.40.206, when formfill is disabled a site with multiple username/passwords does not list them upon clicking on the username field. Verified for 220.127.116.11pre that usernames are listed upon clicking on the username field. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:18.104.22.168pre) Gecko/2007011103 BonEcho/22.214.171.124pre
You need to log in before you can comment on or make changes to this bug.