Open Bug 227632 Opened 17 years ago Updated 6 months ago

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


(Toolkit :: Password Manager, defect, P3)





(Reporter: bugzilla, Unassigned)




(Whiteboard: [passwords:http-auth])


(1 file, 3 obsolete files)

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: 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
2. Enter "test1" as your username and password.
3. Save the password with the password manager.
4. Close Firebird.
5. Visit
6. Enter "test2" as your username and password.
7. Save the password with your profile manager.
8. Close Firebird.
9. Visit

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

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.
Same result on Linux build of Firebird 0.7.
Apologies for bugspam, but I thought that might be useful.
Confirmed. Placing a dependency on bug 222653 since the issue is similar.
Depends on: 222653
Ever confirmed: true
OS: Windows 98 → All
Summary: Password Manager does not allow me to select from multiple logins on a cgi/htaccess auth page → Password Manager (http auth) does not allow me to select from multiple logins
Flags: blocking0.8?
not going to happen for 0.8, especially with bryner away
Flags: blocking0.8? → blocking0.8-
Any chance this'll get into 0.9? It's getting real old, real fast :D
Apologies for bugspam, just wondering what'll happen.
possibly related, bug 220022
(happens for http auth only, happens with new password manager only)
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.
Any chance of seeing this for 0.9?
Flags: blocking0.9?
not a blocker, if bryner decides to do it before 0.9 or someone writes the
patch, great.
Flags: blocking0.9? → blocking0.9-
Flags: blocking1.0?
+ing for bryner's attention - probably requires a new prompt dialog with a text
box that feeds its autocomplete widget from pwmgr. 
Flags: blocking1.0? → blocking1.0+
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...
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
Flags: blocking0.9-
Flags: blocking0.8-
p4 priority - not a blocker. if a patch materializes, please nominate for aviary
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** Bug 271213 has been marked as a duplicate of this bug. ***
*** Bug 279399 has been marked as a duplicate of this bug. ***
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?
Flags: blocking-aviary1.1?
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.
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

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.
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.
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.
Doesn't look like a patch will be forthcoming here, not going to block on this,
try for next cycle.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
No longer depends on: 222653
*** Bug 303238 has been marked as a duplicate of this bug. ***
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?
developers are stupid lazy **** who can't solve a simple problem for
1,5 years
Reference comment #22:  It works quite well for Mozilla 1.7.11, which is why I
won't change to Firefox.  
Trying for next cycle. Anyone willing to get take this on for 2.0?
*** Bug 320821 has been marked as a duplicate of this bug. ***
Any workaround for this really frustrating bug?
Flags: blocking-aviary2?
-> defaults, helpwanted
Assignee: bryner → nobody
Flags: blocking-aviary2? → blocking-aviary2+
Keywords: helpwanted
QA Contact: davidpjames → password.manager
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.
Retriaging, this isn't a P1 blocker, but we'll happily take a fix.
Flags: blocking-firefox2+ → blocking-firefox2-
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.
*** Bug 268081 has been marked as a duplicate of this bug. ***
Assignee: nobody → michael.wu
*** Bug 321476 has been marked as a duplicate of this bug. ***
Bug 265780 will make this relatively easy to do.
Depends on: 265780
Assignee: michael.wu → nobody
The testcase no longer exists, so I've updated it.

Steps to Reproduce:
 1. Visit
 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
 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
Assignee: nobody → dolske
Blocks: 376668
Keywords: helpwanted
Priority: P4 → --
Target Milestone: --- → Firefox 3 M8
Version: unspecified → Trunk
Attached patch Something like this? (obsolete) — Splinter Review
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.
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.
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Duplicate of this bug: 374784
Note to self:

For URLs like "", 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.
We could just show a password prompt, but there are possibly phishing issues.
Is this bug really different from bug 222653?  For a while (1.5 yr), this bug depended on bug 222653
Yes. This bug is specifically about the popup window you get when you go to a site requesting HTTP authentication (eg, 222653 is about form fields in content.
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.]
Attached patch Patch, work in progress (obsolete) — Splinter Review
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).


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. :)
Attachment #279300 - Attachment is obsolete: true
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?
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.
Attached patch Patch for review, v.1 (obsolete) — Splinter Review
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.
Attachment #284206 - Attachment is obsolete: true
Attachment #285637 - Flags: review?(
Is this patch against trunk or stable?
Trunk, of course. This kind of change isn't suitable for branch, IMO.
Sync to current trunk.
Attachment #285637 - Attachment is obsolete: true
Attachment #286103 - Flags: review?
Attachment #285637 - Flags: review?(
Attachment #286103 - Flags: review? → review?(
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Duplicate of this bug: 402040
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-. :-)
Flags: blocking-firefox3?
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
Priority: -- → P4
Untargeting; size of patch + depth of review queue makes this unlikely to hit FF3.
Target Milestone: Firefox 3 M10 → ---
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.
Assignee: dolske → nobody
Priority: P4 → --
Attachment #286103 - Flags: review?(
Product: Firefox → Toolkit
so what's the latest thinking?
Duplicate of this bug: 452280
I wrote these comments Jan 15 2008, I'm reproducing them here now for posterity.

Comment #50 from Justin Dolske <>  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.

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;
Duplicate of this bug: 542172
7 years of this problem and nothing? :-(
There are even older bugs in Mozilla's bugzilla. Many of them ;)

In SeaMonkey this is missing, too :(
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 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.
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.
Does the test case in the first comment also apply to "Mozilla" "Seamonkey" "Nightly" "Trunk" builds?
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: Gecko/20100601 SeaMonkey
Duplicate of this bug: 673065
Duplicate of this bug: 880559
See bug #348941, which describes the inability to select from multiple passwords when user IDs and passwords are entered on separate Web pages.
Duplicate of this bug: 982756
Duplicate of this bug: 608459
Summary: Password Manager (http auth) does not allow me to select from multiple logins → Allow user to select among multiple saved logins in HTTP Basic and Digest Auth dialogs
Blocks: passwords-2015
No longer blocks: passwords-2015-Q1
Whiteboard: [passwords:http-auth]
No longer blocks: 376668
See Also: → 376668
Duplicate of this bug: 1431014
Priority: -- → P3
Duplicate of this bug: 1073599
Duplicate of this bug: 1638671
You need to log in before you can comment on or make changes to this bug.