258543 - Disabling form autocomplete prevents selecting from multiple saved logins

Status: VERIFIED FIXED

(Toolkit :: Password Manager, defect, P1)

Description

[Jim Ginn]

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.

Comment 1

[Peter van der Woude [:Peter6]]

confirming

Comment 2

[Jim Ginn]

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.

Comment 3

[Jim Ginn]

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.

Comment 4

[:deanis74]

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.

Comment 5

[Jim Ginn]

Thank you Dean, I appologize for the bugspam.

Bug 249610 does look like the best bet.

Comment 6

[Neil Williamson]

*** Bug 259019 has been marked as a duplicate of this bug. ***

Comment 7

[chris hofmann]

sounds like this is mostly fixed -minus for 1.0

Comment 8

[:deanis74]

Chris, where did you see that this is mostly fixed?  Re-nominating.  If I missed
something, minus this again.

Comment 9

[Jim Ginn]

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).

Comment 10

[Justin Kerk]

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.

Comment 11

[chris hofmann]

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?

Comment 12

[tyl2]

Re the last comment, this bug causes inconvenience, but Bug 249610 is a security
concern.

Comment 13

[Matt]

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.

Comment 14

[Jim Ginn]

Updating. Sorry for Bugspam.

Comment 15

[Mike Connor [:mconnor]]

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.

Comment 16

[lccha+mozbugs]

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.

Comment 17

[Mike Connor [:mconnor]]

ultimately, this is still a minor bug, and there are bigger fish to fry.  Minusing, will take patch.

Comment 18

[Jim Ginn]

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?

Comment 19

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

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.

Comment 21

[Jim Ginn]

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.

Comment 22

[Jim Ginn]

Renominating now that there is a patch...

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 24

[:Gavin Sharp [email: [e-mail]]]

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... :(

Comment 25

[Jim Ginn]

FWIW, I have been running this patch for almost two months and I have not come across any regressions.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

(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 27

[Mike Connor [:mconnor]]

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.

Comment 28

[:Gavin Sharp [email: [e-mail]]]

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

Comment 29

[Allan Bush]

Working on trunk.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060827 Minefield/3.0a1 ID:2006082704 [cairo]

Comment 30

[:Gavin Sharp [email: [e-mail]]]

VERIFIED fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060828 Minefield/3.0a1.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 226097 [details] [diff] [review]
patch

Drivers: see comment 20, comment 25.

Comment 32

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 33

[Majken Connor [:Kensie]]

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.

Comment 34

[Ari Brener]

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.

Comment 35

[Steve England [:stevee]]

Yes. the bug has been fixed on the trunk (road to Firefox 3.0)

Comment 36

[Jim Ginn]

This has baked on the trunk for a while with no known regressions. Can this be checked in on the 2.0 branch?

Comment 37

[Jay Patel [:jay]]

Comment on attachment 226097 [details] [diff] [review]
patch

Approved for 1.8 branch, a=jay for drivers.

Comment 38

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.js 	1.479.2.213

Comment 39

[alice nodelman [:alice] [:anode]]

Confirmed existence of bug in 2.0.0.1, when formfill is disabled a site with multiple username/passwords does not list them upon clicking on the username field.  

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

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/2007011103 BonEcho/2.0.0.2pre