227632 - Allow user to select among multiple saved logins in HTTP Basic and Digest Auth dialogs

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[Ben Basson]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

If you go to the url: http://www.rillaspora.net/tmp/test/ with my build of
Firebird, you cannot select from multiple logins, Firebird always seems to pick
the first it comes to (although this sometimes appears to be random).

I was told on MozillaZine that you can choose from different logins using the
down arrow key to trigger the autocomplete widget for the username field. In the
test case (and other sites where I originally discovered the problem) this moves
the cursor to the end of the field and no widget is triggered. The only option
is to retype the username and password.

Reproducible: Always

Steps to Reproduce:
1. Visit http://www.rillaspora.net/tmp/test/
2. Enter "test1" as your username and password.
3. Save the password with the password manager.
4. Close Firebird.
5. Visit http://www.rillaspora.net/tmp/test/
6. Enter "test2" as your username and password.
7. Save the password with your profile manager.
8. Close Firebird.
9. Visit http://www.rillaspora.net/tmp/test/

Actual Results:  
One of the two usernames "test1" or "test2" is chosen, seemingly at random, but
it ususally is one of them (consistently). Closing the browser occasionally
changes the username that is picked, but not often. Autocomplete widget should
be shown for the login, but it is not. There is no way to select between the
multiple logins.

Expected Results:  
Firebird should have displayed an autocomplete widget or provided some other way
of choosing between the username/password combination used for this auth form.

Bug occurs with clean install/clean profile.
UA String: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007
Firebird/0.7

Apologies if this bug is already filed. I looked for a dupe, but was unable to
find something that exactly fitted this specification. There were many bugs
mentioned on a related theme. If one of them covers this, please mark this as a
dupe and I'll repost my testcase to the other bug. Thank you.

Comment 1

[Ben Basson]

Same result on Linux build of Firebird 0.7.
Apologies for bugspam, but I thought that might be useful.

Comment 2

[David P James]

Confirmed. Placing a dependency on bug 222653 since the issue is similar.

Comment 3

[Mike Connor [:mconnor]]

not going to happen for 0.8, especially with bryner away

Comment 4

[Ben Basson]

Any chance this'll get into 0.9? It's getting real old, real fast :D
Apologies for bugspam, just wondering what'll happen.

Comment 5

[Nitin (vfwlkr)]

possibly related, bug 220022
(happens for http auth only, happens with new password manager only)

Comment 6

[Tony Bullock]

Folk, why could we not have the same facility as already exists in the Mozilla
browser?  Presumably it would not be difficult to transfer the code?  The
Mozilla method of handling multiple logins for the same web address is splendid.
 Not being able to do this in FB is frustrating.

Comment 7

[Ben Basson]

Any chance of seeing this for 0.9?

Comment 8

[Mike Connor [:mconnor]]

not a blocker, if bryner decides to do it before 0.9 or someone writes the
patch, great.

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

+ing for bryner's attention - probably requires a new prompt dialog with a text
box that feeds its autocomplete widget from pwmgr. 

Comment 10

[Gert-Jan Vons]

I noticed that some other password manager issues have been fixed recently
(thanks guys!), but is there any news on this particular issue?

I have three different accounts on a company web site, using user names and
passwords that are almost impossible to remember.
With firefox I have to look them up in my Palm every time I visit this website,
while Mozilla simply displays all three and I only have to click on the right one.

This problem is the only reason why I also keep a version of Mozilla around;
starting mozilla just to visit this site is still easier than looking up the
account info and typing them into firefox' dialog...

Comment 11

[Ian Pottinger]

I've noticed when using the lastest builds that double-clicking the username
textbox opens the autocomplete drop-down with all remembered userids listed [see
Bug 173569] 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040730
Firefox/0.9.1+

Comment 12

[Asa Dotzler [:asa]]

p4 priority - not a blocker. if a patch materializes, please nominate for aviary
approval. 

Comment 13

[Phil Ringnalda (:philor)]

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

Comment 14

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

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

Comment 15

[Ben Basson]

Nominating for 1.1? This is still a big usability problem for people, such as
myself, administering many hosting accounts from the same control panel, and
countless other applications (including some forms of webmail).

It this fixable in the 1.1 timeframe?

Comment 16

[John David Galt]

Pardon me if I'm being stupid, but I can't reproduce this.  After following
steps 1 through 5 in the description, I am not prompted for a username and
password.  Firefox just uses the ones saved in step 3, which is what I would
want it to do.

Comment 17

[Ben Basson]

You're not reproducing the bug because you didn't follow all of the steps. 

You are correct that at step 5, Firefox fills in the username and password
fields with the values you entered in step 3. However, at this point you delete
the contents of those fields and enter new login details ("test2" instead of
"test1").

When you then proceed to step 9, you are presented with _either_ the values from
steps 2 & 3 _or_ the values from steps 5 & 6. Which of these sets of login
details are picked seems somewhat random, and there is no way the user can
choose, either via autocomplete, up/down arrow keys or a drop-down list.

Comment 18

[John David Galt]

That's impossible to do.  The pop-up dialog which asked for the user name and
password does not reappear on the screen AT ALL.

Comment 19

[Ben Basson]

You need to follow every single step. This is and was always possible. I just
ran through the steps again to verify that they were still correct and that the
testcase page/domain are still functioning.

If you don't close Firefox, you don't end the current session, and therefore
when you revisit the page you are not presented with an HTTP auth prompt, you
simply continue to be logged in. If you're closing Firefox and you're being
automatically logged in when you re-open it, that is _not_ the default behaviour.

To the best of my knowledge, the offending code has not been altered in at least
a year and a half and this bug has been confirmed for the same amount of time.

Comment 20

[Mike Connor [:mconnor]]

Doesn't look like a patch will be forthcoming here, not going to block on this,
try for next cycle.

Comment 21

[Jesse Ruderman]

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

Comment 22

[Artem S. Tashkinov]

I just wonder if this feature is working fine in Mozilla Browser (from Mozilla
Suite), why not copy-paste the code from Mozilla to Firefox?

Comment 23

[Horse]

developers are stupid lazy **** who can't solve a simple problem for
1,5 years

Comment 24

[David E. Ross]

Reference comment #22:  It works quite well for Mozilla 1.7.11, which is why I
won't change to Firefox.  

Comment 25

[Ben Basson]

Trying for next cycle. Anyone willing to get take this on for 2.0?

Comment 26

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

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

Comment 27

[Jan Herold]

Any workaround for this really frustrating bug?

Comment 28

[Mike Connor [:mconnor]]

-> defaults, helpwanted

Comment 29

[Lupin III.]

This is the most annoying bug that up to now kept me from switching to Firefox. I'm trying once in a while (like right now), just to see it still isn't fixed. This bug is open for over 2 (in words TWO) years, from version 0.7, times where the browser wasn't even called Firefox. A feature that works perfectly in Mozilla!

By the way: is there a way to use the password manager with multiple form-logins (not http) with disabled "form completion"? Should be fixed, too.

Comment 30

[Mike Connor [:mconnor]]

Retriaging, this isn't a P1 blocker, but we'll happily take a fix.

Comment 31

[Gregory Baldwin]

Why does not someone create a Firefox plugin for this feature.  I too will not switch from Mozilla to Firefox until I can see a listing of my multiple logons.  My wife and I have many instances in which we each have a secure logon to the same site.

Comment 32

[Phil Ringnalda (:philor)]

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

Comment 33

[Michael Wu [:mwu]]

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

Comment 34

[Michael Wu [:mwu]]

Bug 265780 will make this relatively easy to do.

Comment 35

[Ben Basson]

The testcase no longer exists, so I've updated it.

Steps to Reproduce:
 1. Visit http://www.cusser.net/misc/firefox/testcase/
 2. Enter "test1" as your username and password.
 3. Save the password with the password manager.
 4. Clear Private Data (authenticated sessions and cookies).
 5. Close Firefox.
 6. Visit http://www.cusser.net/misc/firefox/testcase/
 7. Enter "test2" as your username and password.
 8. Save the password with your profile manager.
 9. Clear Private Data (authenticated sessions / cookies).
10. Close Firefox.
11. Visit http://www.cusser.net/misc/firefox/testcase/

Comment 36

[Justin Dolske [:Dolske]]

Attachment: Something like this?

Biesi/Gavin, what do you think about doing something like this?

promptAuth() currently only accepts a single nsIAuthInformation as input, so this would add a new promptAuthMulti() to the prompt service which accepts an array of nsIAuthInformation. The implementation would allow the user to select one by username (or enter a completely new username/password, of course), and it would be returned via |aAuthInfo| just like promptAuth() does.

Comment 37

[Justin Dolske [:Dolske]]

Condensed from IRC:

Biesi commented that using nsIAuthInformation to pass in the extra login information was kind of inelegant, as it drags along some extra fields that are not really needed. The alternatives (multiple arrays of strings or a new XPCOM interface) didn't seem strongly appealing, though.

Instead, it might be best to just bypass the promptService for this, and implement my own XUL prompt which can allow selecting from multiple accounts -- the prompt service being a convenience for simple prompts, and this being a special-case complex prompt. [I suppose some fallback would be needed to the current scheme for embedding platforms which don't have XUL?]

I'm going to start down this implementation path.

Comment 39

[Justin Dolske [:Dolske]]

Note to self:

For URLs like "ftp://[e-mail]", aAuthInfo.username is already set when promptAuth() is called. We should probably handle this like when filling in forms (ie, don't clobber username, look for a login with a matching username). But in this case, I'm not sure if we're allowed to let the user chose a different username that the URL specified.

Comment 40

[Bradley Baetz (:bbaetz)]

We could just show a password prompt, but there are possibly phishing issues.

Comment 41

[David E. Ross]

Is this bug really different from bug 222653?  For a while (1.5 yr), this bug depended on bug 222653

Comment 42

[Justin Dolske [:Dolske]]

Yes. This bug is specifically about the popup window you get when you go to a site requesting HTTP authentication (eg, https://intranet.mozilla.org/). 222653 is about form fields in content.

Comment 43

[David P James]

Re: comment #41

Justin (comment #42) is correct. I filed bug 222653 and triaged this one. They are separate. Bug 222653's problem was that the autocomplete dropdown widget wouldn't show up unless you activated it by using a down arrow or by commencing the typing of one of the other usernames. In this one, the problem was that there was no way to access other usernames at all; one had to type them in in their entirety. Fixing this bug would get Firefox to the same state for auth that it is already in with respect to forms (i.e. bug 222653). I placed a dependency on bug 222653 because it didn't seem worth "fixing" this bug to a state where it would still require another fix (something like 222653) to make it user friendly, but strictly speaking to fix this does not require fixing 222653, which is probably why the dependency was lifted (but from the user perspective, both should be fixed at the same time).

[Don't ask me about when this or the other will be fixed: I have no idea as I am not associated with Mozilla. I used to triage bugs but do not anymore, partly because the developers didn't seem to communicate even the vaguest of intentions to volunteer triagers. The above comment was simply entered for the benefit of those who didn't know why there are two apparently similar bugs in bugzilla.]

Comment 44

[Justin Dolske [:Dolske]]

Attachment: Patch, work in progress

I checked with bz to see if bypassing promptService and implementing the new prompt directly in XUL would be a bad idea. He was generally ok with that as long as non-XUL apps were not expected to use this (I'd probably want a fallback anyway).

However...

As I started poking deeper, I felt this was a bad idea. I really don't want to fork the existing prompting stuff (code + XUL). That's likely to lead to regressions and differences in behavior. The existing prompting code is already tangled enough (or, has a "finely tuned history" :-), and adding Yet Another Code Path wouldn't help the situation. [I think this area is ripe for a major cleanup in Moz2, but that's not an option for 1.9 at this point.]

My next idea was to reuse the existing commonDialog.xul, but avoid going through the promptService... This also ends up being messy, because the prompt service is doing a significant amount of work to set up strings and the awful nsIDialogParamBlock stuff. "Avoiding" the promptService means I would have to fork all that code (and probably port to JS in the process). Yuck.

So, I think the most sensible option is what I've done here, and was basically my original suggestion... Add a couple of extended interfaces (inelegant as they may be!), but maximize reuse of the existing code. 

The biggest chunk of new code is nsPromptService::PromptMultiUsernameAndPassword(), but it's modified cut'n'paste of the ::PromptUsernameAndPassword() function next to it, so I think that's ok (compared to, say, porting it to JS and dropping it into some report portion of the tree).

I'm currently passing around arrays of usernames and passwords, which is a bit verbose in terms of function arguments. Not sure how much can be done about that, though.

This patch is mostly functional, but not strongly tested. It also needs code in commonDialog.js/xul added to handle selecting logins from the menulist... I was more interested in getting the list populated than making it work. :)

Comment 45

[Justin Dolske [:Dolske]]

Forgot to add:

Note that I've adding a promptAuthMulti to nsIPromptService3 [in addition to the existing promptAuth in nsIPromptService2]... But am NOT adding a promptAuthMulti to nsIAuthPrompt2/3. nsIPromptService and nsIAuthService are deceptively similar, and I wasn't clear about this before.

Biesi, maybe this was part of your objection to the original idea? I agree that having a promptAuthMulti in nsIAuthPromptX would be bad, but it's not needed. Does this WIP patch look sensible enough to continue with?

Comment 46

[Christian :Biesinger (don't email me, ping me on IRC)]

I guess my main objection was the argument list of the new functions... but if doing this differently takes too much code then I'm ok with this.

Comment 47

[Justin Dolske [:Dolske]]

Attachment: Patch for review, v.1

Cleans up last WIP, extends nsIPromptServce2 instead of adding nsIPromptService3 [discussed this with biesi on IRC].

General overview of patch:

* Adds promptAuthMulti() & promptMultiUsernameAndPassword(), which pwmgr can provide multiple username/password strings to.

* Modify nsLoginManagerPrompter.js to call the new multi method, and handle return values as appropriate.

* Tweak existing usage of nsIDialogParamBlock. ::Select was using integer #2 in a nonstandard way, and the in-value had a different meaning than the out-value. I needed to use integers in the same way, so I added 2 new reserved ints (#7, #8), gave them enum labels, and made ::Select use them too.

* Modified commonDialog.xul/.js to include a combobox for selecting from multiple available logins.

Comment 48

[Artem S. Tashkinov]

Is this patch against trunk or stable?

Comment 49

[Justin Dolske [:Dolske]]

Trunk, of course. This kind of change isn't suitable for branch, IMO.

Comment 50

[Justin Dolske [:Dolske]]

Attachment: Patch for review, v.2

Sync to current trunk.

Comment 52

[Justin Dolske [:Dolske]]

Requesting blocking, since there's a patch on hand.

...Although Magic 8-Ball says "outlook not so good", since this was already blocking-aviary1.0-, blocking-aviary1.5-, and blocking-firefox2-. :-)

Comment 53

[Justin Dolske [:Dolske]]

Untargeting; size of patch + depth of review queue makes this unlikely to hit FF3.

Comment 54

[Justin Dolske [:Dolske]]

We may want to just entirely rethink this approach as part of a bigger cleanup to the prompting code in Mozilla 2. No one (including me :) was really thrilled with this patch, but it seemed the least-awful way to accomplish it in FF3 while tiptoeing through the prompting code.

Comment 55

[Marc Bejarano]

so what's the latest thinking?

Comment 57

[timeless]

I wrote these comments Jan 15 2008, I'm reproducing them here now for posterity.

Comment #50 from Justin Dolske <[e-mail]>  2007-10-24 18:42:16 PDT
> Created an attachment (id=286103)

Index: embedding/components/windowwatcher/public/nsIDialogParamBlock.idl

 interface nsIDialogParamBlock:  nsISupports {

  /** Get or set an integer to pass.
+   * Index must be in the range 0..8

Index: embedding/components/windowwatcher/public/nsIPromptService2.idl
@@ -44,35 +45,116 @@ interface nsIChannel;
 interface nsIPromptService2 : nsIPromptService {
+  /**
+   * promptMultiUsernameAndPassword()
+   *
+   * Similar to promptUsernameAndPassword(), which puts up a dialog with
+   * fields for entering a username and password. This method allows the
+   * caller to provide known usernames and passwords, which the user can then
+   * select from.

i really don't like this. it's too pushy. can't we get this right finally?

first: there's no way for the callee to ask to delete things, which is
a problem.
less important, you haven't said whether it's possible for there two
be two slots with the same username, but different passwords. (for
some reason i can imagine wanting this, but if you don't want this,
you should indicate that it won't happen)
also, this api is not moving towards being async friendly, it's more
stack unhappiness.

Why can't we provide a nsIWritablePropertyBag and let the prompter
perform mutation operations on it?

+   * @param usernameCount
+   *        Number of usernames provided in the array.
+   * @param passwordCount
+   *        Number of passwords provided in the array.
+   * @param usernames
+   *        An array of usernames.
+   * @param usernames
+   *        An array of passwords. The username at usernames[i] should have the
+   *        its associated password stored at passwords[i].
+   * @param aSelectionIndex
+   *        The index of the default username to be selected. Specify -1 to
+   *        indicate that there is no default. Upon return, will store the
+   *        index of the username selected by the user. If the user edits the
+   *        username field, aSelectionIndex will be -1. Editing the password
+   *        field does not change aSelectionIndex -- if it is not -1 upon
+   *        return, the caller should check aPassword to see if the user has
+   *        changed their desired password.
+   * @param aUsername
+   *        The default value for the username field. Ignored unless
+   *        aDefaultSelection is -1. Upon return, will store the username
+   *        selected or typed by the user.
+   * @param aPassword
+   *        The default value for the password field. Ignored unless
+   *        aDefaultSelection is -1. Upon return, will store the password
+   *        selected or typed by the user.
+  boolean promptMultiUsernameAndPassword(
+              in nsIDOMWindow aParent,
+              in wstring aDialogTitle,
+              in wstring aText,
+              in PRUint32 usernameCount,
+              in PRUint32 passwordCount,
+              [array, size_is(usernameCount)] in wstring usernames,
+              [array, size_is(passwordCount)] in wstring passwords,
+              inout PRInt32 aSelectionIndex,
+              inout wstring aUsername,
+              inout wstring aPassword,
+              in wstring aCheckMsg,
+              inout boolean aCheckState);

Index: embedding/components/windowwatcher/public/nsPIPromptService.idl

  enum {eButtonPressed=0, eCheckboxState=1, eNumberButtons=2,
+        eDelayButtonEnable=6, eNumItems=7, eSelectedIndex=8};

Index: embedding/components/windowwatcher/src/nsDialogParamBlock.h
-  enum {kNumInts = 8, kNumStrings = 16};
+  enum {kNumInts = 9, kNumStrings = 16};

Index: embedding/components/windowwatcher/src/nsPromptService.cpp

+nsPromptService::PromptMultiUsernameAndPassword(nsIDOMWindow *parent,
+  NS_ASSERTION(usernameCount > 0, "must have at least 1 user");
+  NS_ASSERTION(usernameCount == passwordCount, "must have 1 pass per user");
+  NS_ASSERTION(*aSelectionIndex >= -1 && *aSelectionIndex <
usernameCount, "invalid default selection");

if this is going to be exposed to extensions, you should probably
error or console-ReportError.


+  // 16 strings are available by default, 0-12 are used. There's no good way
+  // to check what the maximum already-used index is, so assume 16 is safe
+  // because it can't be exceeded without calling SetNumberStrings anway. Ick.

wow.
wouldn't this be so much better with a bag? :)

+  // Merge the arrays into: [user1, pass1, user2, pass2, ...]

what if a username includes ','?


Index: toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js

    promptAuth : function (aChannel, aLevel, aAuthInfo) {
+        function loginSortByUsername(a,b) {

not sure it matters, but if i ever go to a site where i'm logging in
as 10, 1, 15, 2, 26, this is a bad algorithm :)

I think neil has some js you can use to make things better.

+            var userA = a.username.toLowerCase();
+            var userB = b.username.toLowerCase();
+            if (userA < userB)
+                return -1;
+            if (userB > userA)
+                return  1;
+            return 0;

Comment 59

[S474N]

7 years of this problem and nothing? :-(

Comment 60

[Artem S. Tashkinov]

There are even older bugs in Mozilla's bugzilla. Many of them ;)

Comment 61

[realname]

/vote

In SeaMonkey this is missing, too :(

Comment 62

[David E. Ross]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

I don't see this in SeaMonkey.  After entering my master password (if I did not do so earlier), I can indeed choose the login from a list.  This requires clicking in the ID area on the login page.  The list shows the saved user IDs.  

However, this feature is not consistent.  Sometimes, I have to click once; sometimes, I have to click twice.

Comment 63

[Robert Kaiser]

David, this is not about logins on an already loaded web page, but about the HTTP Auth popup dialogs you get in probably rare cases *before* you even see anything loaded of the page.

Comment 64

[Worcester12345]

Does the test case in the first comment also apply to "Mozilla" "Seamonkey" "Nightly" "Trunk" builds?

Comment 65

[realname]

Test case: 404 not found.

But on other sites with http auth it is reproducible.

Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.1.11pre) Gecko/20100601 SeaMonkey

Comment 67

[Brian S. Craigie]

This bug has been open since 2003.  Couldn't it be given a bit higher priority?

Thanks,

Brian

Comment 69

[David E. Ross]

See bug #348941, which describes the inability to select from multiple passwords when user IDs and passwords are entered on separate Web pages.

Comment 71

[tolgay007]

We are still waiting,please mozilla fix it.

Comment 72

[Artem S. Tashkinov]

A patch implementing this feature was posted almost seven years ago, I guess there's no need to wait for this bug to be fixed. Mozilla just doesn't care. And Firefox 29 clearly shows it. Most power users will hate with a passion.

Comment 73

[tolgay007]

Still not fixed.Please Mozilla do something.

Thanks

Comment 78

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 17 duplicates, 69 votes and 72 CCs.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 79

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.