Closed Bug 258543 Opened 18 years ago Closed 16 years ago

Disabling form autocomplete prevents selecting from multiple saved logins


(Toolkit :: Password Manager, defect, P1)






(Reporter: jcginn, Assigned: Gavin)



(Keywords: regression, verified1.8.1.2)


(1 file)

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,, (when it still allowed saved logins) and a
couple of internal sites at my university. JunkieV at 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.
Ever confirmed: true
Version: unspecified → 1.0 Branch
Flags: blocking-aviary1.0?
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.
Keywords: regression
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.
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
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
Flags: blocking-aviary1.1?
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
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
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.
Flags: blocking-aviary2? → blocking-aviary2+
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-
Keywords: helpwanted
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.
Attached patch patchSplinter Review
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 →
Keywords: helpwanted
Attachment #226097 - Attachment description: patch? → patch
Attachment #226097 - Flags: review?(bryner)
Target Milestone: --- → Firefox 2 beta1
Version: Trunk → 2.0 Branch
Whiteboard: [patch-r?]
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]

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]

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
Closed: 16 years ago
Priority: -- → P1
Resolution: --- → FIXED
Whiteboard: [patch-r?]
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.
Attachment #226097 - Flags: review? → approval1.8.1?
Comment on attachment 226097 [details] [diff] [review]

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:

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?
Flags: blocking1.8.1.2?
Attachment #226097 - Flags: approval1.8.1.2?
Flags: blocking1.8.1.2? → blocking1.8.1.2+
Comment on attachment 226097 [details] [diff] [review]

Approved for 1.8 branch, a=jay for drivers.
Attachment #226097 - Flags: approval1.8.1.2? → approval1.8.1.2+
Whiteboard: [checkin needed (1.8 branch)]
mozilla/browser/base/content/browser.js 	1.479.2.213
Keywords: fixed1.8.1.2
Whiteboard: [checkin needed (1.8 branch)]
Confirmed existence of bug in, when formfill is disabled a site with multiple username/passwords does not list them upon clicking on the username field.  

Verified for that usernames are listed upon clicking on the username field.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/2007011103 BonEcho/
Product: Firefox → Toolkit
See Also: → 751235
You need to log in before you can comment on or make changes to this bug.