Password asked separately for each tab that requires it (proxy)

If it's the prompt for the master password, then that's PSM, not password manager.

Cannot reproduce. Under prefs>Privacy>Master passwords, which radio button do
you have selected?

> Under prefs>Privacy>Master passwords, which radio button do
> you have selected?

"The first time it is needed".

The first scenario is a dupe of bug 96896. The second is not reproducible on
Win2000, Linux, or Mac OSX 10.2.2. cc <email address hidden>, Password Manager
QA, for comments.

*** This bug has been marked as a duplicate of 96896 ***

Verified duplicate.

> The second is not reproducible ...

I've just reproduced the second scenario using bugzilla.mozilla.org login form
in one window and bugzilla.redhat.com one in another. BuildID 2002112018 (trunk)
compiled and running on Red Hat Linux 8.0

Sending to Password Manager

Reassigning to new module owner

I can confirm the second part under Win2k. I have a webmail login as my start
page for mail. The username/pass are stored in the wallet. When I start mail for
the first time (master pass set to check first time needed) I will sometimes get
2 master password prompts depending on the load time for the web browser (one
for IMAP and one for the webmail login form). The first appears to be the
webmail form the second is the IMAP info. If I enter my master password in the
first dialog and cancel the second things still work properly. I'm using

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

I observe another bug that may or may not be related: when I want to cancel
entering of the Master Password, I have to do it twice in a row.
It occurs on http://ej.ru/forum/index.php (need to have a stored password to there).

I found some interesting info related to this bug.
I had a problem of SeaMonkey asking for the Master Password 8 times every start-up.

I could enter the MP once and cancel the other dialogs (in the right order, because a newer dialog blocks the old, so you have to cancel the newest first), instead of entering it the 8 times.

I though it was related to a profile corruption, because it happened just to one of my profiles, but I was wrong.

Today I migrated from a own Inbox for each account (each one of them getting new mail at Mails start-up) to a Global Inbox for every account, except the IMAP one.

Now it prompts for the password just twice.

It looks like SeaMonkey makes all of the requests before one of them ask for the MP, then each of the requests maintains the state that the MP wasn't entered and each one of them asks for the MP, even if a lot of them already asked for.

Putting the accounts in the Global Inbox made SeaMonkey make the requests in sequence, it just starts downloading from one account after the other have finished.

It's a good idea to make multiple requests, if we can, off course.
So it is not a good solution to make every password request synchrony, but should be verified if the MP was requested at the time of making a new MP request, instead of the server (page) password request.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060816 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060816 BonEcho/2.0b1

If I have several tabs open on a site that uses HTTP Basic authentication or similar, then each tab will prompt for a username and password when the session is restored.

I have to fill in the username and password for each tab otherwise it will fail to load. This also occurs if I have a master password set. I have to enter the master password for each tab on the site.

It seems the problem is that all the prompts appear at once, one in front of the other. If only one prompt appeared at a time (per window), then a second prompt would not appear for a site that had already been logged into.

Reproducible: Always

Steps to Reproduce:
1. Enable session restore from options
2. Open two tabs on a site that has HTTP Basic authentication
3. Restart browser

Actual Results:
Password is asked for twice

Expected Results:
Password is asked for only once

I made a simple test case that I could link to for people to try out, but for some reason it did not trigger this bug.

This test case is here: http://www.stonie.co.uk/firefox/testcases/password/
The username and password is 'test'.

However, I can still reproduce this on several real world sites I use. I will need to investigate a bit to find out what's causing this.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060911 SUSE/1.5.0.7-1.2 Firefox/1.5.0.7
Build Identifier:

When clicking an URL to start-up Firefox, I am asked for the Master password multiple times for proxy authentication.

Reproducible: Always

This happens with Firefox 2.0 RC2 (please discard user-agent string). I think I've seen it since the first 2.0 beta I tried (I know, I should have reported it earlier).

Is this a dupe of bug 230190?

(In reply to comment #2)
> Is this a dupe of bug 230190?

In its content, it might seem like it except that for me, it's a new issue with the 2.0 branch. It surely didn't happen with previous releases (except for extensions check).

To verify the above paragraph, I went back to 1.5 to test. I could not reproduce it. That is what I expected. Now, going back to 2.0RC2, I can't reproduce it either when I had it everyday!!

I now see two options: I will see it again tomorrow after I have restarted my PC or, well, this is a config issue that got solved by itself.

I'll come back to this ASAP. Normally tomorrow. Feel free to close (WFM) this bug in one week's time without news from my side.

I regularly experience this bug with nightly builds of Bon Echo and also Trunk builds (not sure if that's the same but I think it is). In particular it happens when I have multiple home pages set (that require proxy) or when the session restore opens multiple tabs.

Regression range for the Bon Echo branch:
Works: 2006072004
Does not work: 2006072103

I don't see any checkins that might have caused this in this range but there are two patches for the password manager that went in on 20060719 just after 17:00.

I was going to say that the problem was gone but it re-appeared today. It is then somehow intermittent. To be continued...

I just saw this with RC3. Just in case it would change something, I disabled all my extensions... Anybody else tried this already?

I had this issue this morning with all extensions disabled.

Having a go with the updates disabled...

(stop me if you think it's useless!)

Having the automatic updates disabled didn't help. I am not thinking of anything else to try right now...

(In reply to comment #6)
> I just saw this with RC3. Just in case it would change something, I disabled
> all my extensions... Anybody else tried this already?

I think I should have been clearer in comment #4 : I tested this with zip builds of Bon Echo nightlies by unzipping to a clean directory and testing with a clean profile created just for this testing. I always see this problem when I'm behind an authenticated proxy with a master password set for every build I've tried after 2006072103.

I am interested to know if you or anyone else is unable to reliably replicate using my method. To be clear:

Steps to reproduce:
1. Use an authenticated proxy
2. Save password for proxy using password manager
3. Set master password
4. Set multiple homepages (outside proxy)
5. Restart Firefox

I've noticed a few other things while testing this:

1. When the master password dialog is only needed for filling out forms there is only one prompt.

2. When multiple pages are loaded by session restore (e.g. after ending task) there are multiple prompts even in builds before 2006072103. I haven't narrowed that down yet, but it started after 2006051503.

3. Without a master password multiple proxy authentication requests are displayed (sometimes need to wait a few seconds before clicking OK, otherwise the second dialog won't pop up.)

4. Setting one homepage to a login form (with a saved password) and the other to a page outside the proxy also causes multiple master password prompts.

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

WFM using latest branch on Mac. Loaded 2 tabs, each with your example URL. Restarted browser with session restore enabled. I got prompted for credentials only once, and after entering them, both tabs loaded fine.

Hm, I'd wonder about platform difference, except justdave is also on Mac...

try having different sites in the different tabs. It may also require multiple windows rather than just multiple tabs. Most of the times I've run into it I've actually had multiple windows open (with multiple tabs in each). Some in intranet, some in nagios, some in the internal sysadmin wiki, etc.

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

Just a +1 on this issue. It is very annoying as I get bit by it every time after Firefox crashes (and tries to load all tabs that I had open).

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

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

Definition of the bug is a bit narrow - if I type from address bar quickly several pages on start-up, it will also ask multiple times for master password, and it is the same bug, I think.

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

I see this in seamonkey 1.1.1 if I set the master password to last for only 5 minutes. When it checks mail, it needs the master password. Each such check seems to display a new master password request. I came in this morning and there were 72 of them!!!

The correct action is to block on the first request until the user answers it.

As a result, it is only feasible to set Mozilla to ask for the Master Password the first time it is needed. This makes things a lot less secure IMHO.

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

This is happening in Seamonkey, too. Not sure the Suite/Seamonkey suffered back when bug 230190 was reported (people then mentioned switching back to Mozilla to get fixed but maybe it was an older Mozilla vs. a newer Firefox).

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

FYI all - I've run into this consistently, though I have Nagios as well as a number of passworded wiki sites (many different hosts) each asking for passwords. I frequently have to wait for Firefox to start and load all pages except password protected pages, then begin typing passwords. What a pain in the backside.

I believe this to be a bug in the security portion of Firefox as the problem has been around long before the Session restore functionality was added.

See bug 225710 for the first documented bug I could find on it (nearly 4 years ago). Bug 369963 is pretty much the same bug, just opened more recently on it.

Just a thought, but would it be possible to open the password manager dialog to receive the master password BEFORE any of the tabs are initialized so that saved passwords can be put into the authentication dialogs as they appear? Still annoying to have to go through and click Okay on all those dialogs (of course this is another issue) but one heck of a lot better than this startup horror that I have to endure every time I open firefox.

(In reply to comment #13)
> Just a thought, but would it be possible to open the password manager dialog to
> receive the master password BEFORE any of the tabs are initialized so that
> saved passwords can be put into the authentication dialogs as they appear?

While it would be possible to ask for the master password in advance, we can't tell whether we'd actually need it. For my part, I'd be quite annoyed to enter the master password at every startup even when it's not needed at all (especially since we also restore cookies which in many cases make it unnecessary to re-login).

I have done some testing with firefox 3.6b5 and this bug is not fixed.
Which surprises me as the proxy auth bug which is similar IS fixed.
Now here is a race condition. If you have mutitple tabs with password forms and an authenticating proxy it depends what comes first.
If the proxy kicks in first, you get a single master password prompt and no prompt at all for the forms in the tabs.
If the proxy is late, then you get a master password for each tab and one for the proxy.

What I don't get, as many other people, is why this has not been fixed all together instead of one for proxy auth, one for basic auth, one for form auth and so on?

Result: firefox is still as "unusable" as before and even got a more erratic behaviour inside enterprises: sometimes it works sometimes not.

Also why has this new bug appeared whereas form based multiple prompts have already been discussed in other bugs for years? Looks to me as if people want to evade the issue.

I didn't mean 93 and 94 to suggest a disagreement, I think those two are the same bugs, just giving different explanations on how to replicate the issue.

In one of the many comments in all these bugs, someone suggested the one and only correct solution: Create a global lock for *all and any kind of dialog*.

Even if you pop up just a single dialog per proxy, master password, site auth, ...., that still means that I can get a second dialog while I'm typing in the first. I can type text blind but not passwords. So I'll always press RETURN for the wrong dialog.

Therefore, FF must never open a second dialog, no matter what.

A great optimization would be to wait for asking for anything until I open a tab which actually needs the password.

Along the same lines, I don't see how this bug depends on bug 513534. I would say it's the other way around: When the dialogs have become sequential, we can start on the optimization.

I wonder if we should have a generic framework that enables us never to ask for the master password twice at the same time in a more general way - Standard8 has been working on something for Thunderbird to make things better there, not sure how much it would fit that...

When I start up Firefox (3.5.5) I have lots of tabs.

I get SIXTEEN password popups! I type my password into the first one that lets me type and hit Enter. The popup doesn't disappear. A new one pops up on top of it. Sometimes it pops up while I'm typing in the first one, grabbing some of the newly-typed characters.

When there are lots of password popups, ONLY ONE of them will take input or honor its buttons. This turns "entering your password" into a game of whack-a-mole, trying to guess which one of the sixteen popups will let me hit Cancel! I'm not sure what else is going on (probably the page loads for each of the tabs), but it's REALLY SLOW, so it takes several minutes before a real firefox window appears!

I'm updating the patch for this bug, and am curious what people want to happen for one specific situation:

Suppose you are restoring a session in which there are multiple HTTP Auth requests for different servers. One master password prompt will be displayed while the others wait. Now, suppose for some reason you click Cancel instead of entering the master password. What should happen to the pending auth requests, and why (what's your use case)?

1) Cancel all of them. [No further MP or HTTP prompts displayed while restoring]

2) Cancel only the prompts for which you have stored logins. [ie, no further MP prompts.]

3) Don't cancel any of them. As each is processed, ask again for the Master Password if there are stored logins for the site.

4) Don't cancel any of them, but don't prompt again for the Master Password while restoring [thus, each prompt will be empty, with no login prefilled].

I'm planning on implementing #1, on the theory that if you're restoring a large number of tabs but click Cancel for the MP, you don't want bothered with any more prompts. The user might even just be borrowing someone else's computer, and has no interest in authenticating to anything (eg, they just want to check gmail). You can, of course, reload any tab to trigger the MP/HTTP auth again.

#3 is the easiest, but I don't think it's very useful (it just leads to clicking Cancel over and over). #4 may be rather hard to do due to implementation details.

#4 seems is an interesting option however I don't think it would be appropriate without also making the other options available to the user. Perhaps these four cases can be implemented as an option in a separate feature request.

Personally I prefer #1.

Does the above logic apply when the multiple prompts are not for a restore, such as when we click a bookmark with multiple tabs or quickly open multiple links in new tabs?

If the master password prompt only came up when you clicked the tab with the logins then I'd definitely say #3. However, based on my usage the master password comes up for all tabs at once, so #1 makes the most sense. It doesn't make sense to me to cancel it once and then want to enter it directly after.

Any are an improvement over the current situation, but my suggestion is to give the user the choice; add a Cancel All button.

A Cancel All button sounds the most transparent and in keeping with current methodologies. I thought you could always utilise the hang down (probably not the right name for it) that comes up across the top of a web page to ask if you want to save a password and instead give an explanation of the Cancel All, something like that.

Implement *anything* and do it *before* 3.6 goes bad! The cancel button is an interesting piece of UI ambiguity but if it delays this patch by even a single hour, drop the work on it and open a new bug to fix it later.

To solve the ambiguity, you'd need a way to tell the user "There are N other pages which also need the master password", otherwise she can't make an educated decision. If you can't provide this data, then "Cancel" must be equals "Cancel All" (otherwise, it would be pointless to even have a Cancel button).

If "Cancel" isn't always "Cancel All", then what does a single cancel mean? Why would the user cancel a single MP request? Is there a situation where this would make sense at all?

As I see it, there is never a situation where I want to provide the MP for some connections but not for others. So when I press cancel, I just want to get rid of the damn dialog, period. That's why I think it's always "Cancel All". If you can, then set a flag not to ask again for the MP until all tabs have loaded and close the dialog.

If there is no simple way to implement this, then just open a new bug and concentrate on fixing the issue at hand.

I largely agree with Aaron. It is imperative to improve on the current situation before the next FF release. So, solution #1 would be the best to pursue in the short term.

In the long-term (i.e. *after* the next FF release), I would opt for a refinement of #2. From my use of FF, it is quite common to only want to enter the master password (e.g. to quickly access your email) and skip any other password prompts for later. So, a more flexible solution would be the following:
   * "Cancel" for master password prompt would cancel all prompts for which you have stored logins. This prompt should appear before any other prompts for which you have no credentials stored.
   * For the remaining prompts that have no stored logins there will be an additional "Cancel All" button. The number of prompts that will be canceled with this button should also be displayed (as Aaron proposes).

Unless the user wants to enter passwords for only some of the non-master password prompts, this solution is almost* optimal in terms of required user effort. Here is a table of usage scenarios and the associated user effort:

    | master password
    |----------------------------------------------------------------
    | | enter | do not enter
---------------------------------------------------------------------
    | enter | 1 master passwd | 1 click
    | all | + | +
    | | 1 passwd per other prompt | 1 passwd per other prompt
  p | | (minimum effort) | (minimum effort)
  a |----------------------------------------------------------------
o s | enter | 1 master passwd | 1 click
t s | some | + | +
h w | | 1 click or passwd | 1 click or passwd
e o | | per other prompt | per orther prompt
r r |----------------------------------------------------------------
  d | enter | 1 master passwd | 2 clicks
  s | none | + | (minimum effort + 1 click)
    | | 1 click |
    | | (minimum effort) |

*The "almost" is because of the extra click in the last cell of the table.

Dolske, as long as we have popup password prompts for HTTP Auth, #1 is best, I think. If we (ever) switch to in-tab-prompts, then #4 seems to be best, but I think it should be up to the bug doing the different prompting to care about that.

That said, I'd really prefer when the password prompts (normal and master) would be deferred until I actually click on the tab which needs them. But again, this is another story. Let's just get the "single password prompt" working. This bug is several years old and it's such a pain that I'm willing to spend money on the fix. Justin, do you have a PayPal account?

solution #1 is fine for the short term. Ultimately I think we are going to want to switch to a model where the master password is presented in manner more analogous to OS user accounts (and is only entered once to log into the browser).

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

(In reply to comment #31)
IMHO those tabs requiring access to secrets protected by the master password would "queue" a request for the master password. Once the master password is entered, all those requests would be fulfilled. What should happen if the user presses "Cancel" for the master password? As the user doesn't know the order of requests in the queue, the obvious solution IMHO would be to annotate the master password dialog with the number of requests (e.g. "Master password (7 requests)"). Then, if cancelling that, it should be obvious that those 7 requests cannot continue until a master password is entered. Also the reasonable solution IMHO would be either to cancel all requests in the queue if the master password isn't entered, or to keep all requests in the queue, and re-open the prompt for the master password (while there are requests in the request queue). Obviously the second solution is not what the user might want.
Independent from that is the effect that most tabs will still want to access the secrets, so they might re-queue requests and thus re-open the prompt for the master password.

Let's go with option 1, no need to add a "Cancel All" button since adding a string will make it impossible to back-port this to 1.9.2 when it's done.

(In reply to comment #31)

#1 is fine. The only reason I hit cancel right now is so that I can dismiss the 4 or 5 dialogs that pop up for me on session restore. Assuming I only got one prompt, the only reasons I would hit cancel would be because I'm offline, or know that I don't want any of the tabs from session restore.

Patch v.3 happens to be applied on top of a minor security patch in my queue, so I've marked it as private, just to be extra cautious. I expect to be able to unmark it shortly.

My suggestion is: when Firefox starts and each tab begins to load, some of them ask for password. FF should ask user for master password (showing only one window). If the user clicked cancel, FF should stop asking. But when user enters some page that depends on password FF should ask ONCE more. If user cancels again, FF should quit asking (until FF restarts).

This is still open on 3.5.7.

Not only that but the dialogs must be addressed in reverse order. Can we at least prevent these from being modal. This always comes up whenever I want to CHANGE my proxy settings. Why isn't there an option to do so? - "USE DIRECT CONNECTION INSTEAD," "SHUT UP AND LET ME BROWSE," or something.

(In reply to comment #31)
> I'm updating the patch for this bug, and am curious what people want to happen
> for one specific situation:

I vote for #1 too.

I haven't any problem with thunderbird 2.23 - now I update TB to version 3.0 and I have been asked for:
1. Master password
2. 1st Password to google calendar in lightning for 1st google calendar
3. 2nd Password to google calendar in lightning for 2nd google calendar

I have 3-rd google calendar yet (totally i have 3 calendars), but for 2 of them I use the same google login - so Thunderbird prompts me about passwords for callendars ony 2 times.

I think I should be prompt only once to type master password.

Thanks for the feedback everyone, case #1 from comment 31 is what I'm implementing here. Any further refinements should be requested in separate bugs.

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

Another bug marked as a duplicate, even though the status of this bug is marked as resolved fixed. It is still an ongoing problem so it is not fixed.

This is not a dup of bug 356097. Bug 356097 is for *proxy* authentication only and was only fixed for that particular scenario. Unfortunately, there are many other reasons why one could get multiple master password prompts (password forms in multiple tabs, etc) and those are not yet fixed.

The FIXED resolution of this bug means exactly one thing: proxy authentication on startup does not cause multiple master password prompts in Firefox 3.6 and later.

The master password prompt can still appear multiple times in other cases -- the causes are tracked in bug 177175, recently reopened. There is one such case known at this moment, and it's being worked on for the next version of Firefox.

Some reports of MP appearing multiple times were marked as duplicates of this bug, even though they were not specifically about the proxy authentication. Sorry about the confusion. If there are specific bugs about other causes (i.e. not master password caused by form fill), please mark them as blocking bug 177175.

> Some reports of MP appearing multiple times were marked as duplicates of this
> bug, even though they were not specifically about the proxy authentication.
> Sorry about the confusion. If there are specific bugs about other causes (i.e.
> not master password caused by form fill), please mark them as blocking bug
> 177175.
Thank you for that clarification

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

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

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

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

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