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

[Álvaro del Olmo Alonso]

Binary package hint: firefox

Ubuntu 8.04 - Hardy (development branch)
FIrefox 3 Beta 3
I am connected through a proxy that needs authentication and I have multiple tabs opened.
When main Firefox window is closed (selecting "Save and Quit" later) and I open Firefox again, multiple windows appear (one for each tab) asking for me user and proxy password. There should appear only ONE window.

[Morse (morse)]

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

[Junruh (junruh)]

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

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

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

"The first time it is needed".

[Junruh (junruh)]

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 ***

[Junruh (junruh)]

Verified duplicate.

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

> 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

[Junruh (junruh)]

Sending to Password Manager

[Hjtoi-bugzilla (hjtoi-bugzilla)]

Reassigning to new module owner

[Retrev (retrev)]

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

[Mhz-altlinux (mhz-altlinux)]

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

[Asrail (asrail)]

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.

[Bugzilla-pdjs (bugzilla-pdjs)]

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

[Bugzilla-pdjs (bugzilla-pdjs)]

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.

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Gavin Sharp (gavin-sharp)]

Is this a dupe of bug 230190?

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Wildmyron (wildmyron)]

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.

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Patoche-smart+mozilla (patoche-smart+mozilla)]

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

[Wildmyron (wildmyron)]

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

[Adam Guthrie (ispiked)]

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

[Dietrich-mozilla (dietrich-mozilla)]

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

[Justdave-mozilla (justdave-mozilla)]

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.

[Adam Guthrie (ispiked)]

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

[Georgi Georgiev (chutz)]

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

[Ria-klaassen (ria-klaassen)]

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

[Philringnalda (philringnalda)]

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

[Ivan Icin (ivanii)]

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.

[Philringnalda (philringnalda)]

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

[Jamesrome-alum (jamesrome-alum)]

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.

[Dveditz (dveditz)]

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

[Dveditz (dveditz)]

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

[Ria-klaassen (ria-klaassen)]

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

[Kbenton (kbenton)]

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.

[Morac99-firefox (morac99-firefox)]

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.

[oneguycoding (steeve-oneguycoding)]

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.

[Zeniko (zeniko)]

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

[Justdave-mozilla (justdave-mozilla)]

Session restore is basically useless for me because of this. Frequently when I have to restore I wind up with a mess of my tabs with an "Untitled" title, and the little spinner going forever until I close the tab. My best guess is whatever was trying to load in that tab gave up when the passwords weren't immediately available at restore time. This is a dataloss issue, because many of the tabs don't actually restore because of this.

[oneguycoding (steeve-oneguycoding)]

I would like to echo Mr Miller's comments. At the very least this bug should be escalated to raise its severity level.

In reply to Mr Bunzil, one could tell whether the master password is required in the session if a flag existed to indicate whether a tab exists that required a password. Not sure if that approach would be possible.

An entirely viable alternative would be a feature that requested the master password early in the startup process. 'Prompt for master password on startup?'.

[Reed Loden (reed)]

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

[Jesus Cea (jcea)]

I hit this bug also.

[Radoslaw Grzanka (radoslawg)]

This is problem for me when I have two plugins that (upon firefox startup) tries to login to services (like, for example, Gmail notifier and gmail reader notifier). I have to retype master password twice before finally firefox shows main window.

Additionally, what is perhaps more irritating, when first prompt for master password shows and I start typing in, then second one shows and I finish my password in second dialog box. This results in a mess. So I'm +1 for fixing this issue.

[Mitchs-bugzilla (mitchs-bugzilla)]

Just to restore a one-tab session on Firefox 3 beta 2, I get two master password prompts and 3 proxy prompts, and they're not saved yet because I haven't put in my master password. 5 dialog boxes in total for one tab using Weave and Gmail checker.

[Thorsten Hirsch (t-hirsch)]

Even when I set a master password, I'm still prompted for the proxy authentication for every tab. And still it doesn't remember my user name or my password. Sometimes I'm even prompted several times for one tab - I guess that has something to do with the ads on the page.

It's very annoying when firefox opens several tabs at startup: for this session (5 tabs) I had to fill out the dialogue box 8 times! (Firefox 3 beta 2)

[David+bugzilla (david+bugzilla)]

This happens to me with Firefox 3.0b2 on Mac OS X (10.5.1).

I do not remember this happening on Firefox 2.

Even worse than asking for the same password 15 times (literally--I keep a lot of windows and tabs open), is that if I don't get rid of the dialogs fast enough they get locked up stop rendering themselves. It seems that sometimes it asks for the master password with a sheet, and sometimes with a dialog box.

When I have both sheets and dialogs open (because I didn't cancel a sheet quick enough) then sometimes a sheet wont render (it's just a blank sheet, password-asking sized). Also subsequent dialogs wont render either.

Once it's locked up I cant get rid of the sheet and so the whole window will not respond to any input. I have to quit firefox and hope that next time it comes up the timing will be slightly different...

[Jack-hh (jack-hh)]

You'd think it wouldn't be too hard to make password lookups funnel through a single opportunity to ask for the master password, that each page-load blocks on simultaneously, instead of a zillion times. The master password already gets modal on you anyway, so I don't see it costing much in terms of usability.

[Flory (flory)]

I am getting the same behavior with the session restore flag set to true to to false. This does not occur in FF2. For me the main problem occurs when I use the "Open all in tabs" option on a bookmark directory with several sites that have registered passwords with the FF password manager.

Result: multiple requests for the FF password manager password.
Expected: one request for the password.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008020804 Minefield/3.0b4pre ID:2008020804

[Jose Carlos Garcia Sogo (jsogo)]

This is still happening with Firefox 3.0Beta3. While it was annoying in firefox 2.0 to be asked several times for user/passwd, at least fields were autofilled, which is no longer happening with this new version.
Also, as some other users are experiencing, loading sites like iGoogle makes firefox ask several times for this authentication.

[Gavin Sharp (gavin-sharp)]

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

[Álvaro del Olmo Alonso (dllum)]

Binary package hint: firefox

Ubuntu 8.04 - Hardy (development branch)
FIrefox 3 Beta 3
I am connected through a proxy that needs authentication and I have multiple tabs opened.
When main Firefox window is closed (selecting "Save and Quit" later) and I open Firefox again, multiple windows appear (one for each tab) asking for me user and proxy password. There should appear only ONE window.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

bug 369963 is a Core bug - is there any reason to believe this bug isn't a duplicate of it (that is, specific to SeaMonkey?)

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

(In reply to comment #14)
> bug 369963 is a Core bug - is there any reason to believe this bug isn't a
> duplicate of it (that is, specific to SeaMonkey?)
>
This bug ended up with "Product: SeaMonkey" as a result of a ping-pong between various product values back in 2002...

[Jamesrome-alum (jamesrome-alum)]

It seems impossible to select multiple products when you enter a bug.

[Bill+mozilla-bugzilla (bill+mozilla-bugzilla)]

I see this bug depends on bug 369963 - is there anything about this bug that's unique, such that this isn't a duplicate of bug 369963? I realize this bug is somewhat older, but the trend is to dup against the root-cause bugs.

[Bmo-2 (bmo-2)]

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

[Bmo-2 (bmo-2)]

mtschrep: can you flag this wanted:1.9 as was the case for bug 369963?

[Hskupin (hskupin)]

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

[Justdave-mozilla (justdave-mozilla)]

FWIW, this is more tolerable than it used to be. It used to hang half the time when there were multiple of these prompts, and they'd all pile on top of each other, and half the time the one with focus wasn't the one in front. Now the one it front seems to get focus, and after entering the password in that one, I can just cycle through the rest of them and hit OK and they all continue and do what they need to even without entering it (because it was unlocked by the first one).

But it's still a pain. Would be nice if the security UI was queued, and only one could open to prompt the user at a time, and if a page was requesting something the user already did (like unlock the master password) it would just return to the user without prompting once it got to that point in the queue.

The same thing seems to apply to website http auth passwords. I can have 6 or 8 tabs open in the same website and on a session restore, every one of those tabs will prompt me for the website password after the master password is in, even though they're all for the same site and answering it for the first time would have satisfied the rest.

[Justdave-mozilla (justdave-mozilla)]

(In reply to comment #23)
> I see this bug depends on bug 369963 - is there anything about this bug that's
> unique, such that this isn't a duplicate of bug 369963? I realize this bug is
> somewhat older, but the trend is to dup against the root-cause bugs.

Bill: yes. This bug report is describing a problem seen by users of Firefox. The problem at this point appears to be caused by an external component (the Security Manager) and not Firefox itself. However, if this bug is closed, people searching Firefox bugs won't find it. And the bug in Security Manager getting fixed won't necessarily fix this one, because Firefox includes a specific version of the Security Manager and not the same tag as the Firefox you're building. So after that bug is fixed, then Firefox has to be updated to include the version of Security Manager that it gets fixed in (which is what this bug will do I presume).

[Hskupin (hskupin)]

Bugs mentioned in comment 4 are bug 221634 and bug 343182. The patches were created by Michael Wu. Perhaps he can help?

Does anyone of you notice this behavior on another OS as Windows? I think it should also happen.

[Dolske (dolske)]

The cause is known, it's an architectural issue with how prompts work. All these bugs about getting multiple prompts share the same root problem.

[Nick Barcet (nijaba)]

I am having the same problem with web sites that requires an authentication through a 401 Auth requested type error.
This is on Firefox-3.0~b4+nobinonly-0ubuntu1 on Hardy.
The problem cannot be reproduced on Firefox 3.0 b4 on MacOSX.
There are no errors displayed by firefox on stderr when invoking it through the command line.

[Nick Barcet (nijaba)]

Note that the problem still occurs with extensions disabled.

[Álvaro del Olmo Alonso (dllum)]

Which team should this bug be assigned to?

[oneguycoding (steeve-oneguycoding)]

FWIW, I still see this behaviour in Firefox 3.0 beta5, although the method that dave Miller mentionned about hitting Ok in subsequent master password dialogs does not work. I still have to enter the master password in each dialog.

[Mitch-1-2 (mitch-1-2)]

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

[Mitch-1-2 (mitch-1-2)]

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

[Håkan W (hwaara-gmail-deactivatedaccount)]

Mitchell, bug 230190 seems to be about *proxies* making multiple prompts appear.

This bug is about having several tabs for the same (HTTP authenticated) site bring up multiple prompts, asking for the same password, unrelated to proxies.

[Morac99-firefox (morac99-firefox)]

Though the triggers are different, it's the same bug so marking this as a duplicate of bug 230190 would seem correct. At the very least this bug should be dependent on bug 230190.

[Bugzilla-pods (bugzilla-pods)]

I thought it was fixed in latest FF3 beta 5 but today I got it again. It is quite annoying. If you click cancel then you get this error and another prompt.

[Exception... "'User canceled Master Password entry' when calling method: [nsILoginManagerStorage::findLogins]" nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: file:///C:/Program%20Files/firefox/components/nsLoginManager.js :: anonymous :: line 455" data: no]

[Stephan-st-strittmatter (stephan-st-strittmatter)]

An easy solution would be to add a flag to be anabled by user to ask always for master password before starting Firefox.
This could be a security-enhancement also for Portable Firefox version to prevent starting without typing in password.
BTW, would be also very nice for Thunderbird.

[Matti-mversen (matti-mversen)]

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

[Louis-Dominique Dubeau (ldd)]

I confirm experiencing the same thing in 3.0b5:

firefox-3.0 3.0~b5+nobinonly-0ubuntu2

This bug was present in FF2 and I know it was reported but I don't remember where. It was never fixed in FF2 and now it shows up in FF3. Yay!

[Alexander Sack (asac)]

this problem manifests itself in xulrunner-1.9

[Timeless-bemail (timeless-bemail)]

Created an attachment (id=318923)
only try once

this isn't terribly useful w/o another patch to another bug (instead of SDR prompts, you get HTTP(S)[Auth/Proxy] prompts, which are not any better).

[Kai Engert (kaie)]

(From update of attachment 318923)
If this is about a race for SDR, don't we need a lock to protect the mBusy state?

What happens to the callers that will get NS_ERROR_IN_PROGRESS? Will they retry or fail?

Are multiple calls to SDR originate from multiple threads, or from event processing on a single thread?

If they originate from multiple threads, maybe we could use a condition variable, block if busy, and signal once done?

If they originated from a single thread (and spinning the event loop), it's probably more difficult to have them retry as soon as we're no longer busy.

[Kai Engert (kaie)]

Do we have stacks?

[Jks-iname (jks-iname)]

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

[Shadowbottle (shadowbottle)]

I have this issue too. I find that if I quickly type in my password on the first master password prompt, before any additional prompts appear, and hit return then everything opens up fine. You have to move fast to get it, though. Just thought some additional detail may be helpful.

[oneguycoding (steeve-oneguycoding)]

I've recently noticed that this is exacerbated when other firefox child windows popup during the request for the (multiple) master passwords. For example, it seems that when installing new extensions FF 3b5 now opens the Addons dialog after restart to inform you that your extension was successfully installed. When this dialog opened it was EXTREMELY difficult to enter my master password for the two tabs that required HTTP authentication, because the keyboard focus kept switching from one dialog to another, I'd put the focus manually in one of the master password dialogs, and start typing and it would lose focus and end up in another master password dialog and so I'd end up typing a partial password. Pretty frustrating.

I first noticed this behaviour with the Alert Slider of the ReminderFox application. Disabling the Alert Slider seemed to ameliorate the nastiness associated with this particular BUG.

FYI, this was observed with Fedora 8 x86_64 running Firefox 3.0b5 (x86).

[oneguycoding (steeve-oneguycoding)]

Suddenly this problem is very bad again. I was asked for my master password SIX TIMES on my last startup! Immediately after installing Firefox 3.0 RC1, although it did the same for me this morning with 3.0b5.

[Mike Connor (mconnor)]

This seems to be an issue caused by extensions. While we could try to bulletproof things, I suspect that multiple MP prompts are caused by repeated attempts to access the software token in NSS. We can't fix that on the front end, since this seems like an extension bug.

[Morac99-firefox (morac99-firefox)]

(In reply to comment #36)
> This seems to be an issue caused by extensions. While we could try to
> bulletproof things, I suspect that multiple MP prompts are caused by repeated
> attempts to access the software token in NSS. We can't fix that on the front
> end, since this seems like an extension bug.
>

This isn't a problem caused by extensions at least not since Firefox 2.0.x. It can be recreated with no extensions installed (in a brand new profile). The simplest way to do so is to have Firefox remember password and set it up to "restore windows and tabs from last time".

At this point, open two windows: one with 1 tab open and one with 2 tabs open. Make sure Firefox has a saved password for Google and then open the following URL in all 3 tabs:

https://www.google.com/accounts/LoginAuth?continue=http%3A%2F%2Fwww.google.com%2F&hl=en

Finally use he File->Exit command. The next time you open Firefox it will show multiple password prompts.

An interesting note, it won't show multiple prompts if there are simply 2 windows open (1 tab each) or if there is one window open with 2 tabs. I'm not sure why.

[oneguycoding (steeve-oneguycoding)]

I also disagree with Mike Connor that this is an extension bug. Although, it may be exacerbated by extensions that need a password. If you have ever experienced this behaviour you will know how frustrating the experience can be of being bombarded by master password dialogs. It is really not a pleasant experience.

There is an implementation issue here, the fact that more than one master password dialog can be open at any one time is the cause. Serializing access to this dialog would be the solution. Embedding the request for the master password in the URL edit control would be another, although that would result in synchronization as well. The reason why I favour the second approach is that it would focus more security related functionality into this part of the interface, as is being done with the anti-spoofing features.

[Justdave-mozilla (justdave-mozilla)]

I also agree with the previous two commenters, and I'm re-requesting blocking on that grounds. If you have multiple windows open that need authentication to be accessed (HTTP auth) and you have a master password set, and you quit and save your session, you will hit this when you start Firefox again. It's a pain in the ass.

[Justdave-mozilla (justdave-mozilla)]

mconnor: if you were basing your "caused by extensions" assumption on my comment 25, I was referring to NSS, which is most decidedly not an extension (just a separate component from the main app, but still shipped as part of the app).

[David+bugzilla (david+bugzilla)]

It goes beyond merely annoying on Mac OS X. As I mentioned in comment 19 it can take a whole browser window out of commission for the session. The only way to get it back is to restart and pray that you can get rid of the password windows fast enough. I'll attach a screenshot of the symptom. Firefox 3.0rc1, by the way.

[David+bugzilla (david+bugzilla)]

Created an attachment (id=321546)
Messed up "sheet" rendering a window useless until restart.

[David-balazic (david-balazic)]

Partly on topic, about dialog vs. URL edit control:

I was always annoyed by the fact that a dialog popped up by one tab prevented me to access the other tabs. Example:
You read instructions on one tab :
 - tab1: "visit this URL"
 - you open that URL in new tab
 - tab1: "click this link"
 - you click the link on tab 2
 - an authentication dialog appears
 - tab1 say : "enter x and y as name and password", but YOU CANT read this, since the dialog blocks you from switching to tab1

[Håkan W (hwaara-gmail-deactivatedaccount)]

I have to agree on blocker nomination.

For people working in offices using intranets (lots of tabs open on many sites requiring the same password) this is almost unbearable on start of Firefox.

[oneguycoding (steeve-oneguycoding)]

This is *exactly* the situation I find myself in, and the thought of restarting Firefox (after an update for example) is unbearable.

[Beckman (beckman)]

Created an attachment (id=321607)
Loading 6 Tabs in New Profile (no Addons) with Master Password shows 3 prompts

Request as well that this issue is blocking. I loaded 6 tabs, 3 of which required HTTP auth -- username and password authentication. This was a brand-spanking new profile, no Addons, Themes or anything, just the plain vanilla 3.0rc1.

All that was changed was to load the last tabs, and the Master Password. Now on startup and loading the last tabs, I am prompted one time for each HTTP auth'ed page.

This causes problems with TabMix Plus as well, using their session manager. However, this issue has been tested with NO ADDONS and it still fails, epic fail.

Again, I re-iterate and support what's been already suggested -- this bug should block 3.0.

[Beckman (beckman)]

Created an attachment (id=321609)
OSX Session Restore using TabMix Plus shows random blank entry

While this is related to how TabMix Plus handles session restore, and I'm not saying that this bug is ONLY with TabMix Plus, recently using 3.0rc1 I found myself facing an empty prompt, possibly the master password prompt. I was able to enter the password and continue (not knowing if the prompt succeeded or failed quietly) and was able to load the session. But I did have to enter the Master Password one time for every TAB that required authentication, either HTTP auth or a remembered username/password for a web-based login.

I've reproduced this both on Windows XP 3.0rc1 and Mac OS X 10.4.11 FF 3.0rc1.

[Zeniko (zeniko)]

Whatever the issue, this isn't Session Restore causing it, as it doesn't prompt for any passwords (and you can get the same issue by saving all tabs to bookmarks, restarting Firefox cleanly and then reopening those bookmarks all at once).

This should be better handled in Core:Security UI (or maybe Core:Networking such as the similar bug 356097).

[Justdave-mozilla (justdave-mozilla)]

renominating blocking since the component move killed it.

[Bclary (bclary)]

fyi, enabling fips with a master password may help reduce the number of password prompts. at least it has made my life more bearable at the cost of the initial master password prompt.

[Justdave-mozilla (justdave-mozilla)]

fips == ??

[Bclary (bclary)]

fips == Federal Information Processing Standard (FIPS)
preferences->advanced->security devices->enable fips mode

[Mike Connor (mconnor)]

This is not a regression from Fx2, not a blocker.

[Jks-iname (jks-iname)]

This may not technically be a regression, but it is much worse in Fx3 than it was Fx2.

[Jdsmet (jdsmet)]

Is this code shared with Thunderbird 3.x ? If so, it's happening there too and definitely a regression vs 2.x.

When using a master password I used to get 1 prompt for it when starting tb, while now I get 1 prompt for each mail account.

[Justdave-mozilla (justdave-mozilla)]

(In reply to comment #53)
> This is not a regression from Fx2, not a blocker.

This most certainly is a regression. Both TB and FF 3 exhibit this problem, TB and FF 2 do not. This particular bug might not be a regression, but the symptoms of it certainly are, and end users are going to think so.

I understand from discussion on IRC that the size of this problem is too invasive on the back end to fix this close to release, so nominating for 1.9.0.1 instead of 1.9

[Håkan W (hwaara-gmail-deactivatedaccount)]

(In reply to comment #56)
> I understand from discussion on IRC that the size of this problem is too
> invasive on the back end to fix this close to release, so nominating for
> 1.9.0.1 instead of 1.9

Did you mean to nominate this for 1.9.1 (or whatever FF.next will be based on)? I doubt this would be accepted in a security release, if the changes would be invasive...

[Håkan W (hwaara-gmail-deactivatedaccount)]

Oh, I guess there's no such blocking flag yet. :-)

[O-e-ekker (o-e-ekker)]

(In reply to comment #50 and #52)
> fyi, enabling fips with a master password may help reduce the number of
> password prompts. at least it has made my life more bearable at the cost of the
> initial master password prompt.
> fips == Federal Information Processing Standard (FIPS)
> preferences->advanced->security devices->enable fips mode

After reading this comment I enabled fips mode, because I figured the button would change to "disable fips mode" after fips being enabled. The button did in fact change, but the button also got disabled itself... Off-list Bob pointed out that Firefox had to be restarted (properly, not killed or crashed) before the button got enabled again so I could "Disable fips mode".
HTH if someone else runs into problems with enabling fips mode

[oneguycoding (steeve-oneguycoding)]

FWIW, when I enabled FIPS mode, I get two master password dialogs, one normal and one FIPS. If I enter the normal one first, and then the FIPS dialog I get no others. It seems that the FIPS dialog is blocking all others.

A reasonable work around, but I still agree with others who consider this bug to be a regression in 3.x.

[Charlie-stigler (charlie-stigler)]

This is a RIDICULOUS blocker, and when I turn on the McAffee SiteAdvisor extension I get the weird blank password prompts too.

[oneguycoding (steeve-oneguycoding)]

I'm going to have to retract my previous statement that enabling FIPS makes this any better. Indeed, with or without FIPS, startup now is becoming ridiculous. This morning I entered my master password SIX times. In the sense that this is getting worse I'd have to say that this is a regression.

I'd vote that this be a blocker.

[Kas-fi (kas-fi)]

I think all pop-up windows (not only the password dialog for basic authentication) should be serialized. I have just found out that the "allow cookie" dialog has the same problem. I have tried to access the following page:

http://www.oracle.com/technology/products/berkeley-db/index.html

which created many pop-up windows asking whether I want to allow or deny cookie from oracleimg.com (or something like that). Even though I have clicked on "remember the decision for this server", I had to answer the same question several times (5-10x, maybe).

[O-e-ekker (o-e-ekker)]

Can someone explain why Thunderbird can handle multiple prompting for passwords and Firefox can not? I thought they would share this Core component. Apparently Thunderbird does serialize the prompts and Firefox doesn't? And for Thunderbird this poses no security risk and for Firefox it is?

[Michal Suchanek (hramrach)]

There are two similar problems here:

1) when there are multiple pages in a session that require password the password is asked multiple times even for the same realm. This probably happens when you do not type the password fast enough for the other tab to start loading when the realm is already authenticated. Similar problem happens for multiple authenticated media in a non-authenticated page (or so I beleive from description of bug 387652).

2) when the password for the site is stored there is a Master password dialog for each basic auth dialog. This is basically the same issue as above, only the the 'realm' here would be the firefox password database.

This happens in both Firefox 2 and Firefox 3 rc

A somewhat unrelated issue is that the auth dialogs sometimes lose focus - this is a general UI issue probably not specific to security. My guess is that password prompts are the only dialogs appearing in sufficient quantity to trigger the bug. Whatever is done to dialogs the one with focus should be the one that is visible - bug 387652.

[oneguycoding (steeve-oneguycoding)]

I can verify that typing one's master password fast enough will avoid the problem, but one must type very very very quickly. One of the frustrating things about thsi bug for me is that more often than not, another master password dialog arrives and steals the bloody keyboard focus, even though the z-order of the new dialog with keyboard focus is below the dialog in which one was just typing. So you end up searching for the dialog with keyboard focus or trying to find a dialog that will accept the keyboard focus because sometimes the edit control seems to be blocked for some of the multitude of master password dialogs.

I see this as a security issue because one ends up blindly retyping one's master password without verifying that it is actually ending up where intended. My feeling is that the master password request should be queued, and only repeated if the previous attempt failed, or if the master password has timed-out for some reason. The password dialog should be replaced by an interface element that exists in the status bar, or the URL edit control or whatever it's called as long as it is made explicitly clear that a request is being made for the master password. The point being that this functionality should be something that cannot be faked by nasty web pages or rogue extensions (regardless of whether anything could be done with the snarfed password).

[Chris Dunning (chris-bluenoteweb)]

I can confirm that this happens on FF3 but did not on FF2. According to help->about I have:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

I am running Kubuntu 8.04 Hardy.

I skimmed through the reports here and did not see my particular use case mentioned. In addition the problems described above when restoring a session with many password-protected pages, I have a problem with one of our internal systems. This system is inside of a password-protected directory (using Apache's .htaccess protection) and loads several pages simultaneously in frames. If I close all FF windows then open this page I am presented with 4 master-password prompts in quick succession, one for each frame on the page. I must fill in my password on all of them before I can move on and get my work done.

This isn't quite a show-stopper for me but it's certainly annoying. I work as a web developer and might at a given time have 3-4 password protected windows up for 3-4 different clients, plus something monitoring servers or watching mail logs. If I put my laptop to sleep then bring it back up later I get a master-password box for each one of those windows/tabs/frames.

@Steve - take a look at bug 101611 for other security issues related to the master password dialog. I like your suggestion to get rid of the popup, similar things have been suggested there.

[Justdave-mozilla (justdave-mozilla)]

(In reply to comment #64)
> Can someone explain why Thunderbird can handle multiple prompting for passwords
> and Firefox can not? I thought they would share this Core component.
> Apparently Thunderbird does serialize the prompts and Firefox doesn't? And
> for Thunderbird this poses no security risk and for Firefox it is?

Because you're using an older version of Thunderbird? The alphas of Thunderbird 3 most certainly *do* have this problem, and it's bloody annoying (I have 7 email accounts in my Thunderbird, so I get prompted for my master password 7 times every time I launch Thunderbird).

[Dolske (dolske)]

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

[Lc--fc-xx001xx (lc--fc-xx001xx)]

On Mac OS X 10.5 it happens right after starting Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0 ID:2008053008 with "Open All In Tabs" even in safe-mode, i.e. with all extensions disabled. And it doesn't happen in Fx 2. Like Chris said, it's annoying, I have that problem every day.

[Niels-keurentjes (niels-keurentjes)]

I would like to echo that this bug is highly annoying. I am a system administrator with several HTTP auth protected Cacti tabs open *always*, and as such I have the "Restore all tabs" option enabled. The bug which asks for the master password once for every password protected tab has been around in every Win32 Firefox version as far as I can remember, up to 3.0rc1 which I'm currently running, independent of the number of plugins installed. It's always asked once per protected tab, and usually in more or less random order depending on how fast the 401 replies dribble in.

I would definitely suggest blocking the entire application once a single Master Password dialog is showing. While I have no inside knowledge of the Firefox code, I would expect the stored password management code to always tunnel through a single entry point when retrieving a login, which would be an excellent place to block with a plain old mutex if the password dialog is already open. That's probably oversimplifying it, but I can't imagine the real solution being much more complex than that.

[Davemgarrett (davemgarrett)]

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

[Cwwmozilla (cwwmozilla)]

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

[Charlie-stigler (charlie-stigler)]

If nothing else, could there be a way to force a master password prompt as Firefox opens, before anything loads, so that no others will appear? This wouldn't be a complete fix, since I know some people don't want the prompt until it's necessary, but it couldn't be very hard to do (it could probably even be implemented as an extension if I knew how).

Oh, and I'll be the first to say that the bug is still there in 3.0rc2, although I'm sure that was expected since there was no mention of anybody working on a patch.

[Jdsmet (jdsmet)]

Using ThunderBird version 3.0a2pre (2008060508), I believe this bug is a lot worse than I assumed. I think the behaviour described below is caused by this bug anyway.

I have my mail accounts set up to automatically check for new mail. I also have it set to remember passwords. This doesn't quite seem to work reliably for my gmail account though, so i frequently have to re-enter my gmail password.

Now, when I got up this morning, Thunderbird had about 50 (!) or so password dialogs up, all asking for my gmail password. And it's not easy to get rid of them either, since all the dialogs are in exactly the same location and modal, but the topmost window wasn't the one that could get focus.

I managed to get rid of a dozen or so, but in the end I just gave up and killed TB.

So this to me is another case of what this bug is really about, i.e. serialising password prompts.

[Mkmelin+mozilla (mkmelin+mozilla)]

That's bug 338549.

[Jruderman (jruderman)]

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

[Jruderman (jruderman)]

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

[josh04 (josh04)]

I get a similar sounding problem with the password manager. If I open a session with multiple tabs which I have passwords set for, the master password window appears multiple times, stealing focus each time which is annoying if I've already begun typing in one.

[TylerJ (gotylergo)]

it happens to me too in firefox 3.0 on hardy with all the latest updates as of june 12, 2008.
it's a really minor problem because all you have to do to get by it is type the password twice or enter the password in one, close the other, and reload the tabs.

[Alexander Sack (asac)]

On Thu, Jun 12, 2008 at 05:11:52AM -0000, TylerJ wrote:
> it happens to me too in firefox 3.0 on hardy with all the latest updates as of june 12, 2008.
> it's a really minor problem because all you have to do to get by it is type the password twice or enter the password in one, close the other, and reload the tabs.
>

thanks for the assessment

 affects ubuntu/xulrunner-1.9
 importance low

 - Alexander

[Kai Engert (kaie)]

So, after having performed my own tests (Firefox 3 RC), let me try to describe and summarize.

I've set Firefox up to use a master password, and instructed it to save passwords.

I've used 3 tabs.
2 tabs go to server A, 1 tab goes to server B.

Each tab requires http basic auth.
The 2 tabs for server A are in the same directory and work with the same user/pass.

Upon session restore, 3 master password (MP) prompts are opened.
As said before, it is sufficient to enter the password once.
In further MP prompts it's sufficient to click OK (without entering the password).

While Firefox does have the site passwords remembered, it brings up prompts for the site passwords, too. Yes, user/password fields are pre-filled, but you get a prompt, and you have to confirm (with OK).

Despite the fact that 2 tabs should obviously work with the same user/pass (same server same directory) I get 3 web site password prompts.

Then I removed the master password and restarted.
Upon next session restore, I no longer got a prompt for the MP, as expected.
However, I still got 3 independent prompts for the web passwords.

[Kai Engert (kaie)]

Do you still believe we are having a dataloss issue here?
Do you still have scenarios where you are unable to re-open tabs?
(This was said earlier in the bug).

[Kai Engert (kaie)]

The subject of this bug is
  "Session restore causes multiple prompts for same password"
and it is currently assigned to
  "Security UI"
which is the component we can declare responsible for bringing up the master password prompt.

We could try to change that to have the other prompts delayed until the result of the first MP prompt. I agree that would be good, and I'll try to look into it.

But what about the prompts brought up by core networking?
Do those bother you, too?
That would require a different fix (and should probably be tracked in a separate bug).

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

(In reply to comment #79)

> But what about the prompts brought up by core networking?
> Do those bother you, too?
> That would require a different fix (and should probably be tracked in a
> separate bug).
>

See tracker bug 95397 for other similar bugs.

[Charlie-stigler (charlie-stigler)]

I'm not sure about what other prompts are like this. I can only think of Master Password prompt, HTTP basic auth, and proxy authentication.

The master password prompt is by far the worst, though, and it also causes those weird blank prompts to popup.

I think the other master password prompts should check if another one is popping up, and then just not popup if so. Similar things should probably be implemented the HTTP basic authentication and proxy authentication.

[Kai Engert (kaie)]

In my test case where I have 3 MP prompts, I see we're going 3 times recursively through nsHttpChannel::PromptForIdentity and PK11PasswordPrompt.

PK11PasswordPrompt brings up the MP prompt, but what should happen when it detects one prompt is already active?

Failing is not an option, IMHO. It would cause all pages but the first one to not restore automatically. Blocking is not an option either, because that would cause a deadlock - the prompt further up on the stack wouldn't have a chance to unblock.

I think a solution is to avoid the recursion at the networking level.

Multiple calls to nsHttpChannel::PromptForIdentity should be avoided.

nsHttpChannel::GetCredentialsForChallenge (which calls PromptForIdentity) should detect whether a prompt is already active, and avoid another one.

I think we need even a platform wide solution.
We should have a singleton that tracks whether any authentication prompt is currently being shown.
Any other code desiring to shown an auth prompt should check whether a prompt is already active.
If "busy", the context can decide to fail, or register for wakeup, using a callback mechanism.

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

(In reply to comment #81)
> I'm not sure about what other prompts are like this. I can only think of
> Master Password prompt, HTTP basic auth, and proxy authentication.

Cookies. I have "ask me every time" for cookies, but I always set the "Use my
choice for all cookies from this site". On "restore session" startups, FF
2.0.0.12 asks for cookie permissions for all sites, including those for each it
already knows my preferences...

[Kai Engert (kaie)]

Could we simply not spin the event loop while we're showing a modal prompt?

[Bzbarsky (bzbarsky)]

No, unless you don't want any repainting to happen, want to block all handling of events in all browser windows, want to block all network requests, and generally make it impossible for the user to interact with the browser until the prompt comes down. Oh, and the user won't be able to read the prompt.

[Niels-keurentjes (niels-keurentjes)]

Well that's effectively what we call 'modal' except for that you could filter WM_PAINT or its non-Win32 counterparts easily. But still, not an ideal solution.

I don't see the real problem. At some point in the security core there's going to be a call to the central password storage, and how hard can it be to put a simple mutex there before opening it so no separate threads can access it simultaneously, thus automatically avoiding simultaneous dialogs on the subject with a few simple lines of code? Release the mutex after either granting or denying access, and there you go.

Only negative side effect would be that in the case of reopening 3 password protected tabs *without wanting to open them*, for example if you have a non-trusted visitor next to your keyboard, you'd have to decline entering the password 3 times. Well, in that case you choose to deny opening 3 password protected tabs explicitly, so that's acceptable I think.

[Bzbarsky (bzbarsky)]

Niels, there's app-modal and window-modal. We don't want these dialogs to be app-modal.

[Niels-keurentjes (niels-keurentjes)]

Why not? In every conceivable use case, the dialog is going to be user-initiated (application startup, surfing to a site or opening a tab or window consciously). In user-initiated situations I don't see a real problem in blocking the entire application for access to an application wide facility.

While I agree right away that window-modal would be better, I would argue it an option to go for a relatively simple solution in 3.0.1 and then fix it better in 3.1 or 3.5. The current problems are worse than the backlash of the quick fix, being that a user cannot continue browsing in a window he wasn't using anyway at the time it popped up.

Also - would the other window block until you also opened a protected site there? In a mutex solution it would only block threads *also* accessing the central password storage, wouldn't it? Again, I'm not familiar with the Firefox code internals, but that's my base assumption here.

[Bzbarsky (bzbarsky)]

Surfing to a site need not be user-initiated by any means. Any web page can do that by setting window.location.

Which means that backgrounds windows, or worse yet windows on different desktops can do stuff that makes the window you _are_ using right now completely unusable.

This is all if we're doing an application-modal dialog. Just blocking on the password store would of course make this less of a problem.

All that said, isn't this basically like the "mailnews prompts are no longer serial" problem that was cut for Gecko 1.9? Sure seems like basically the same issue to me.

[Bzbarsky (bzbarsky)]

I any case, I think I answered the question in comment 84...

[Bzbarsky (bzbarsky)]

And note that the "existing auth prompt on different screen or desktop" problem means that just doing what comment 82 suggests could be a pretty nasty user experience too.

[oneguycoding (steeve-oneguycoding)]

One of the major use problems with this particular functionality bug is that the application (firefox) *is* unusable for the duration of the startup sequence. Indeed, it is the master password dialogs themselves that make the application so difficult to interact with (loss of keyboard focus, switching of keyboard focus while typing in subsequent dialogs). I agree with the comment that blocking access to the master password dialog with a mutex is the short term fix and then fix the overall problem (security, usages, etc) of the master password dialog in a subsequent release. I am happy to test any solution that is provided.

[Honzab-moz (honzab-moz)]

We have two option as far as I understand the code. In both cases we should have a singleton or something that monitors the dialog being pop-up (sets atomically a flag).

1. When the MP dialog is to be open check it is not already displayed (per app or per device) and if so, spin the main-thread event loop until a flag is atomically set after the dialog has been confirmed/canceled. This should be relatively easy and clean to do.

2. Do this asynchronously i.e. return some error code or whatever and let the client wait for callback (something like 'err_retry_auth_on_callback'). As I know the code this isn't easy to do.

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

(In reply to comment #93)

> 1. When the MP dialog is to be open check it is not already displayed (per app
> or per device) and if so [...]

Also, no matter what you do in the second password requestor, you'd also want to re-raise the existing password request prompt.

In addition, it would IMHO be highly desirable to make this code sufficiently generic, so that other kinds of prompts could also use it.

[gmud (gmud)]

>In addition, it would IMHO be highly desirable to make this code sufficiently
>generic, so that other kinds of prompts could also use it.

I think this is desirable, BUT since this bug is so severe for the usage of ff there should be a quick and dirty workaround that solves the issue for password dialogs first. After that a good idea can be found and implemented. This is definitly a show stopper. Actually the session restore should be handled like in ff 2 (only when a crash occurs) and the option to save the session when closing should be disabled until this bug is fixed somehow. It doesn't make sense to introduce a new feature that doesn't work like expected.

[Honzab-moz (honzab-moz)]

--> me, going to work on this.

[Honzab-moz (honzab-moz)]

Created an attachment (id=326384)
Fix, http channel prompt for identity bypass

This is fix based on my letter proposal. The change is specific to http channel and prevents either the master password prompt and proxy username/password prompt to be shown more then ones.

This patch doesn't prevent overlap of username/pass prompts for different realms or web auths and also overlap of MP prompt raised from different places of PSM.

[Honzab-moz (honzab-moz)]

Created an attachment (id=326390)
Improovment to prompt service

This is improvement to prompt service implementing aggregation queue preventing overlap of password type dialogs and aggregates data between multiple instances of the same dialog.

The code is designed to simply allow just a single queue for any dialog or group dialogs of a single type to each have its own queue.

I am not sure of the way how equal dialogs are recognized. I compare fields like title etc. This might rise security risks when dialogs titled the same way comes from different origin.

This patch is not the way to fix this issue, I added it just for reference and because the work has already been done.

[Beltzner (beltzner)]

This doesn't block branch releases, IMO. I'm sorry that it's annoying, but it's annoying for a pretty small subset of our general user population. If we see a well-tested, bulletproof patch nominated for approval1.9.0.1 we might take it on the branch, but I think your better hope is 1.9.1.

[Philringnalda (philringnalda)]

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

[Steve Castellotti (steve-theprofessionalamateur)]

This never happened to me with the 2.x series but happens all the time with 3.0, including the release candidates which were provided with Fedora 9.

If I'm quick and I can type in my master password before any of the other tabs load, I only have to enter it once. If I'm too slow I may have to enter my master password dozens of times, again and again.

I don't believe it affects only session restores, but if I have a group of bookmarks as my "home" setting and more than one requires log in, the same thing occurs.

Very frustrating.

[Steve Castellotti (steve-theprofessionalamateur)]

Created an attachment (id=327337)
screenshot of issue in action

Added a screenshot of the issue in action

[Dolske (dolske)]

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

[Dolske (dolske)]

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

[Dolske (dolske)]

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

[Jcazes (jcazes)]

Any update to this? I have been plagued with multiple master passwords on start up (with previous session/tabs enabled on restart) for as long as I can remember.

Our web software utilizes user authentication, so if I have multiple portals open in tabs when I close the software, reopening yields 2 or more "master password" prompts, PLUS the user authentications for each portal (although, at least those are saved). This gets excessively annoying when I'm closing the software with 5 tabs...

[Honzab-moz (honzab-moz)]

Please, take a look at attachments to bug 348997, mainly the "Improovment to prompt service" (currently just a draft). It probably solves this problem generically.

[oneguycoding (steeve-oneguycoding)]

I wonder if this is "annoying for a small subset of the general user population", because the general user population is just not setting their master password. Since the master password does not need to be set, I'd bet that it's a very small portion of the non-technical user base.

And we're not talking about annoying in my opinion, we're talking about incredibly vexatious to the point where even thinking about restarting firefox is an extremely stressful endeavour.

[Dda (dda)]

I do not have 'master password' enabled, but after FF3 restart if I had 10 tabs opened with the same site (password protected), I'm prompted for the password 10 times. This *is* annoying. In FF2 I was prompted once, and all other tabs with same website were "waiting" until I enter the password, and then opened.

[Markvanbeek (markvanbeek)]

Please solve this :) It was indeed not present in FF2! And looking at the ages and the amount of other duplicate bug reports and responses, I think undoing the re-introduction of this bug will be highly appreciated ;)

[oneguycoding (steeve-oneguycoding)]

Mark, indeed it was present in FF2, it seems to be worse in FF3, and it is much worse when other dialogs popup during the same period that the master password is being requested (like the addons update dialog, or after installing a new extension it pops up now to indicate whether the installation was successful or not, personally I prefer dialogs on error, but I'm picky that way) This bug has been a thorn in my side ever since the FF session restore was added.

[Steve Castellotti (steve-theprofessionalamateur)]

(In reply to comment #106)
> Mark, indeed it was present in FF2, it seems to be worse in FF3

Steeve, That's odd, I never encountered this issue in FF2 or earlier over many years of usage. I was fairly certain as with Mark and other that this was introduced in FF3.

[Daniel Seifert (dseifert)]

I also noticed this in FF2. It got worse in FF3 like steeve said, though to be honest I can't quite quantify this feeling. Maybe it's just the hope gone that FF3 would fix it ;-) As for it only being introduced in FF3, some early comments in this bug describe/imply this issue for FF2, also see e.g. bugs #359878 or 362660 (marked duplicate of this bug, more in the comments above) that clearly describe this issue for FF2.

BTW, I also agree with steeve on comment #103, personally I try to avoid restarting Firefox because it's just such a hassle to restore the session. At one time I seriously considered turning off the master password (I didn't ;-)) as it got so terribly annoying. I have at least(!) 8 password protected (http auth and form based login) sites open in tabs at all times.

[Markvanbeek (markvanbeek)]

Sorry Steeve, I just re-installed FF 2 to check and I really only get one single request for the master password while starting with exactly the same pages as with FF 3...

[Markvanbeek (markvanbeek)]

And yes, I did setup a master password!

[darkangel (lonedesign-2k)]

Mark, as others have said, this *is/was* present in Firefox 2 (see 'proof' in bug 359878 & bug 362660), it's just worse in Firefox 3, so reproducing the issue won't be as simple as duplicating the same set of tabs.

[Markvanbeek (markvanbeek)]

Well, if for me (as an 'end user') following the exact same startup procedure in FF3 result in typing the master password about 15 times and in FF 2 only one time, then I'm not able to reproduce the issue and thus for me the bug is not there in FF 2. But, no offense, shall we leave it at this and just state that it _is_ present in FF 3 and we would really like to have it fixed?

[Shadowbottle (shadowbottle)]

I can again confirm this happens in FF2 just as well and in FF3. It's still annoying as balls and makes the master password useless which really pisses me off in OS X as there's still no keychain integration either. So I either have to deal with a non-password protected password library (which is frickin' retarded) or protected with a guaranteed kick to the groin click-fest full of useless password prompts.
ITS GETTING OLD. FIX THIS SHIT ALREADY. This isn't even CLOSE to new. Makes me pine for phoenix.

[Honzab-moz (honzab-moz)]

Created an attachment (id=329486)
Fix v2, http channel prompt for identity bypass

Thanks Michal's work on bug 387652 I could fix bug in the patch. This is fixed version.

[tdn (spam-thomasdamgaard)]

I can confirm this bug. It is seriously annoying!

[Gabriel Bauman (gabrielbauman)]

If you have loaded extensions that save passwords in the password manager, you get one password dialog per extension, as well as for every loaded page that requires one.

I have a Nagios checker, a GMail checker, and my home page is a secure site on our corporate LAN.

That's three password prompts clobbering each other.

[Matti-mversen (matti-mversen)]

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

[Fjodor (sune-molgaard)]

Patch applies (with offsets) to seamonkey trunk (which exhibits this bug badly for me at every startup), but though the prompts seem to mostly come one or two at the time with it, they still appear for every tab needing login info and for every mail and non-public news account (18 for me, all in all)...

Thanks to everone working on this, however!

[Honzab-moz (honzab-moz)]

Sune, thanks for feedback. I want to ask - those 18 prompts are each for a different credentials (different site/account to log in)? If not, the patch still has gaps. Then, did you let seamonkey remember the credentials in the password manager?

[Fjodor (sune-molgaard)]

Those are all different sites/accounts, yes. And yes, the credentials are set to be remembered in the password manager, protected by a master password.

[Honzab-moz (honzab-moz)]

I see. Then, just to be sure, you see 18 master password prompts or 18 dialogs to enter username and password?

In the letter case if you have to enter username/password pairs again for each site during every seamonkey start then what you have been experiencing is more a problem with the password manager. Anyway, I will try my self with this patch and seamonkey (I was testing just with firefox till now).

[Honzab-moz (honzab-moz)]

One more question: have you also applied attachment 326390?

[Fjodor (sune-molgaard)]

In reverse order of questions, no, I only applied the last one, so I'll go ahead and try with both of them now.

And for the first question, I did/do see prompts for the master password and not dialogs to enter the site specific passwords. Incidentally, only a single one of my tabs, a local nagios page, does http auth and that dialog shows only after entering the master password (with the credentials filled out, of course). The rest are html user/password prompts (and then, as stated, there are the mail and new accounts).

[Fjodor (sune-molgaard)]

Weee, it really worked! :-)

Thanks to all involved!

[Charlie-stigler (charlie-stigler)]

So is this going to be in 3.0.2 then?

[oneguycoding (steeve-oneguycoding)]

Is there anywhere that one can get a build with these patches applied? Or do I have to setup a build environment and apply the patches manually? I'm interested in testing this on a linux i686 build, fwiw.

[Honzab-moz (honzab-moz)]

(In reply to comment #123)
> Is there anywhere that one can get a build with these patches applied? Or do I
> have to setup a build environment and apply the patches manually? I'm
> interested in testing this on a linux i686 build, fwiw.
>

There is no official build because the patches didn't went through review. If you are willing to do testing, please go forward, it will be very helpful to check these patches on other then windows platform (I don't have a linux machine, I just tested on win and mac).

[Fjodor (sune-molgaard)]

"it will be very helpful to
check these patches on other then windows platform (I don't have a linux
machine, I just tested on win and mac)."

My success story with the patches is on X86_64 Linux :-)

[Justdave-mozilla (justdave-mozilla)]

Ya'll will be happy to know these two patches resolve the problem in Thunderbird/Shredder trunk on Mac, as well. :) (In Thunderbird you would get prompted for the Master Password once for each account you had set to check mail at startup instead of just once.)

[oneguycoding (steeve-oneguycoding)]

These two patches do not resolve the problem for me with firefox 3.0.1 on Fedora9, x86_64. I grabbed the fedora src rpm for firefox (firefox-3.0.1-1.fc9.src.rpm), installed it, untarred the firefox-3.0.1-source.tar.bz2 source tarball, applied the two patches (326390 and 329486) and then tarred the patches sources back up again. Then I made the rpm, built it and reinstalled.

Now when I start a session, with two tabs requiring https authentication, as well as an extension that also uses the master password (reminderfox), I still get numerous prompts for the master password. The process is definitely cleaner, but I'm still prompted for the master password many times.

[Tyson-lambert (tyson-lambert)]

I get multiple password manager propts when opening 3.0.1 in the morning with tabs on multiple sites requiring authentication without a proxy involved. This occurs on linux and only began happening with 3.0 release (The RCs did not have this behavior). Possibly related?

[jlmalet (jeanluc-malet)]

I also notice something : you only have to enter the master password once, the others dialogs box that ask for master password can have any wrong value (even leaving the field empty) you just have to press enter or click ok...

[oneguycoding (steeve-oneguycoding)]

I repeated the test on an older system (celeron) with a fresh install of fedora9 i686. Again I patched the source tarball and made a new rpm, installed it (with a forced install btw so I know it's the new version). Then I ran the new copy, setup session restore and a master password and created a couple tabs all pointing to the same https server that requires a single http authentication after which I can get to any part of the web server. I exited and restarted firefox and while the behaviour is MUCH better, I still got two master password dialogs (one for each tab) and the same http authentication dialog for each tab.

[oneguycoding (steeve-oneguycoding)]

I forgot to note that while I got more than one prompt for the master password dialog this time, they were at least serialized so that I didn't have multiple dialogs cluttering up the screen and stealing keyboard focus.

I did not try hitting enter in subsequent master password dialogs without reentering the master password.

[Honzab-moz (honzab-moz)]

Steeve, thanks for a feedback. I will try the same situation in windows and mac. To confirm, the scenario is: 3 or more tabs directing all to exactly the same site needing HTTP auth + setup a master password + saved password for that site. Your result is 2 MP and HTTP auth prompts, right?

I have yet never tried such scenario.

[George Lazarides (george-lazarides)]

This is truly an annoying bug, I have to enter my master password MANY TIMES to get Firefox up. I know I could remove some add-ons to make it better, but the add-ons are one of the best reasons to use Firefox!

You have to enter your password once for each extension that accesses the internet when it starts (which is most of them) and once for each tab that is open (which can be quite a few if you are restarting for any reason). It really adds up!

This should really be a priority to work on.

[oneguycoding (steeve-oneguycoding)]

Honza, I have 2 MP and 2 HTTP auth prompts for the same site. And I just reverified that I have 3 MP prompts on my setup at home, with ReminderFox installed and using the master password to store its network connection information to access a remote calendar at www.icalx.com. IT could be that ReminderFox is complicating my setup and may account for the fact that I do see two MP prompts at once on this box.

I also verified that it is better in that I only have to enter the MP once, after which hitting enter in the dialog is sufficient to continue. Of course, it would be preferable if the MP would not be prompted for after it has been successfully entered.

[Fjodor (sune-molgaard)]

Steeve: Just to be double sure: Your results sound an awful lot like mine, at the point where I had only applied the last patch. Did you, in fact, apply both?

[oneguycoding (steeve-oneguycoding)]

Sure, good idea :) I reversed the patches in the redhat/BUILD directory for both 326390 and 329486. Note the offsets in 329486 which were there also when I applied the patch. The redhat src rpm firefox-3.0.1-1.fc9.src.rpm used firefox-3.0.1-source.tar.bz2. Which source tarball did you use?

[root@linguini mozilla]# patch -R -p1 --dry-run < /data/src/firefox/patch.326390.diff
patching file embedding/browser/photon/src/PromptService.cpp
patching file embedding/components/windowwatcher/public/nsPIPromptService.idl
patching file embedding/components/windowwatcher/src/nsPromptService.cpp
patching file embedding/components/windowwatcher/src/nsPromptService.h
[root@linguini mozilla]# patch -R -p1 --dry-run < /data/src/firefox/patch.329486.diff
patching file netwerk/protocol/http/src/nsHttpChannel.cpp
Hunk #1 succeeded at 118 (offset -1 lines).
Hunk #2 succeeded at 2633 (offset -161 lines).
Hunk #3 succeeded at 2924 (offset -1 lines).
Hunk #4 succeeded at 2792 (offset -161 lines).
Hunk #5 succeeded at 3085 (offset -1 lines).
Hunk #6 succeeded at 2965 (offset -161 lines).
Hunk #7 succeeded at 3290 (offset -1 lines).
patching file netwerk/protocol/http/src/nsHttpChannel.h
Hunk #1 succeeded at 214 (offset -6 lines).
Hunk #2 succeeded at 305 (offset -9 lines).
patching file netwerk/protocol/http/src/nsHttpHandler.cpp
patching file netwerk/protocol/http/src/nsHttpHandler.h
[root@linguini mozilla]# pwd
/usr/src/redhat/BUILD/firefox-3.0.1/mozilla

[Fjodor (sune-molgaard)]

Actually, I use seamonkey trunk, but I don't know that much about the code, so I hope someone else may come up with better suggestions/solutions for you.

[Honzab-moz (honzab-moz)]

So, I applied again both the patches and rebuilt embedding and network modules, for mozilla-central (FF3.1). I had setup the master password and saved 5 tabs all with a same single site needing authentication which I stored the password for. On windows I see just one MP and one username/password pre-filled dialog - so I cannot reproduce the problem. The same with ReminderFox installed. I don't have a linux machine to test.

I will retest this scenario with the latest seamonkey trunk - I could not setup the master password there, it is ignored by the password manager.

[Honzab-moz (honzab-moz)]

(In reply to comment #135)
> I will retest this scenario with the latest seamonkey trunk - I could not setup
> the master password there, it is ignored by the password manager.
>

After complete rebuild of seamonkey and usage of a clean profile I still cannot protect my passwords with the master password. Is it a known bug?

[David-balazic (david-balazic)]

There is a new high to this bug.
I just started my FF 2.0.0.16, the windows appeared. One had an "accept incomplete HTTPS certificate" dialog. O clicked OK and ...
The normal (nonpassworded) tabs were working.
The tabs requering a password were empty with spinning throbber.
No password dialogs anywhere.

I can browse in the loaded tabs. Open new tab and windows.
When visiting a page with password input field and submitting it, that page(tab) hangs too.
Menu File / Exit does not work. (no reaction, I can continue to use FF as if I did not click Exit)

I will now kill it and hope it remembers the tabs.

[oneguycoding (steeve-oneguycoding)]

Created an attachment (id=331791)
Patched fedora 9 firefox 3.0.1 with 3 master password dialogs

After applying the two patches by honzab to the firefox 3.0.1 srpm, I still see multiple master password dialogs. In this image there are three MPs, two of which will accept keyboard input. After clicking enter on these tabs another MP appeared and then showed the same https authentication dialog twice. I reported on this earlier but just wanted to show a demonstration.

[Matti-mversen (matti-mversen)]

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

[Earl Ruby (eruby)]

I have a bookmark with 12 tabs, all corporate Intranet, all requiring passwords. I did not notice this problem in FF2, but the first time I started FF3 I and I opened the 12 tabs I got *12* pop-up Windows asking me for the Master Password, which I'd have to enter 12 times. (Usually I'd just close the window and restart FF3.)

Really annoying.

Under FF2 I'd get *one* request for the Master Password and then separate login password requests for each of the 12 pages (for which I could just hit Enter, since FF would fill those in for me once it had the Master Password).

I worked around the problem by adding the first tab as a separate toolbar bookmark. Now I click that first, get one tab, get asked once for the Master Password, then I log into the page, then I open the 12 tabs. Since I've already entered the Master Password before opening the 12 tabs I don't get asked for the Master Password again.

This problem may be under-reported since it only affects people who (a) bother to set their Master Password, (b) open multiple tabs at once and (c) need passwords for those multiple tabs. Of course if you do fall into this category, it's really annoying, but can be worked-around.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

[Fjodor (sune-molgaard)]

I am unsure if I am seeing a result of this patch, or if the behaviour was like what I am seeing now before it.

Anyways, I am, as noted, happy to only have a single prompt for the MP, but all sites for which login credentials are saved to a cookie, forgoes it's use and present me with either the login page (with credentials filled out as expected), or a generic page, requiring me to go the the site's login page (with credetials filled out) myself.

Note that this is less of an annoyance than the multiple MP prompts, but stil unexpected behaviour.

So, could this be caused by the patch, or should I file an unrelated bug report?

[O-e-ekker (o-e-ekker)]

(In reply to comment #32)
> I also notice something : you only have to enter the master password once, the
> others dialogs box that ask for master password can have any wrong value (even
> leaving the field empty) you just have to press enter or click ok...
>

Great! This saves a lot of typing as long as this bug isn't fixed.

[Celafon (celafon)]

Just to add my 2 gr. regarding master password multiple prompts.

Not sure how the problem was "solved", but in my case I am still seeing the MP multiple prompts. I am using stable release version, so not sure if that applies...

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1)

Wouldn't it be possible to just cache in the saved session the necessity of entering MP for a certain tab(s) and BEFORE the bunch of tabs/windows is loaded, try to ask the MP? Is it possible to show just the dialog without opening any of the main ff windows?

In my experience even if there's no MP required for any of the saved session pages, you will get the prompt sooner or later so asking for MP on start up is OK for me. If that is out of a question then I would like to see an option "Always ask for MP on start-up" which would save a lot of trouble with "Master Password Prompt Hell".

[oneguycoding (steeve-oneguycoding)]

I'd also vote for the always prompt for MP on startup, although that would so thoroughly mitigate the bug that no one would be available to test any fixes :)

Things seem better in the 3.1a2pre. I still see two MP prompts, but the races for the dialogs are gone and keyboard dialog focus is much less frustrating. I"m pretty sure the second dialog is because of one of my extensions (ReminderFox) which stores it's password for network authentication in the password list. And it seems that one only needs to enter the MP once and that hitting enter on subsequent dialogs is all that is required.

One complaint is that entering a wrong password results in another dialog but with no notification that a bad password has been entered. Although this is probably a different bug, possibly the bug concerning the ease with which the MP dialog can be spoofed by nasty unscrupulous people.

[Timeless-bemail (timeless-bemail)]

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

[OGGY (oggysss)]

(In reply to comment #31)
> I get multiple password manager propts when opening 3.0.1 in the morning with
> tabs on multiple sites requiring authentication without a proxy involved. This
> occurs on linux and only began happening with 3.0 release (The RCs did not have
> this behavior). Possibly related?
>
I can confirm this behavior (see bug 450732)

[Jim P (jkpalmer)]

I have the same situation as Earl Ruby. I only have 3 tabs opening, however.

My solution - I close two of the master password message boxes and enter my password in the third, and I'm fine.

Yes, it's annoying.

Would LOVE to have it fixed!!!

-jP

[Christian-binder (christian-binder)]

In conjunction with BUG 448113, this is a thing that should be fixed as soon as possible, cause logins, esp. in large enterprises with intranetservices, get very long winded.

[Zeniko (zeniko)]

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

[Web-fora (web-fora)]

I can confirm that this behaviour is happening in a windows environment as well.

[Zeniko (zeniko)]

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

[Hskupin (hskupin)]

Kaie, do you have a free slot to check your review request for the attached patch?

[Matti-mversen (matti-mversen)]

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

[Honzab-moz (honzab-moz)]

Isn't this fixed in bug 348997 ? (Patches waiting for review)

[Nelson-bolyard (nelson-bolyard)]

Regarding all the denials that this is a FF3 regression,
is this not yet another consequence of the new nsIThreadManager in FF3?
Should this bug be yet another blocker of bug 381699 ?

[Volkmarkostka (volkmarkostka)]

It is a FF2 regression. Just check the user agent of the first post. It is FF 2.0b1.

[Michal Suchanek (hramrach)]

Wasn't FF2 the version that introduced session restore in Firefox? IIRC it was possible only with extensions in earlier versions of Firefox.

It looks like the password prompting is flawed since the start but as new features are added (session restore, improved threading) the flaw surfaces in more and more common use scenarios.

[Fjodor (sune-molgaard)]

Just to reiterate, I see this in seamonkey, which doesn't have session restore. However, I do have a large group of pages set to load on startup, and they trigger it...

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[Brian J. Murrell (brian-interlinx)]

Disagree the importance of this one is "low". It's a very real usability issue. You have 30 tabs and FF3 crashes (for the fifth time that day) on yet another flash site. Now you have to restart FF3 and enter your proxy account and password 30 times.

Is anyone from Canonical or Ubuntu paying attention to this one?

[Matti-mversen (matti-mversen)]

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

[Peter Gervai (grin)]

yes should depend on bug 348997

and yes, it's generally for anything requiring master password, and you may see an amusing screenshot in Bug 456427 ;)

[Peter Gervai (grin)]

(bug 356097 kind of duplicates this one, or at least should depend on this)

[Olivier Kaloudoff (kalou)]

Problem still appears with 3.0.3+build1+nobinonly-0ubuntu0.8.04.1

[Martin Sorgatz (martin-sorgatz)]

> However, I do have a large group of pages set to load on startup, and they
trigger it...

That's it. No session restore necessary, just a start page with several tabs asking for master password.
And therefore I just downgraded to FF 2.0.0.17.

[Dtownsend (dtownsend)]

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

[Bmo-2 (bmo-2)]

this was forward-duped for no apparent gain (and then that bug was duped)

[Bmo-2 (bmo-2)]

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

[Hskupin (hskupin)]

(In reply to comment #20)
> this was forward-duped for no apparent gain (and then that bug was duped)

That was done because bug 369963 contains more information.

[glarbl_blarbl (glarblblarbl)]

Problem also appears in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

I would also like to add that this is the most annoying aspect of firefox into which I have run ;)

[Jo-hermans (jo-hermans)]

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

[Bzbarsky (bzbarsky)]

biesi's probably a much better reviewer for this; both for the HTTP code and the prompt service code, since he's spent a good bit of time thinking about this problem in bug 338549 (which is basically this same bug but for mailnews channels, not HTTP channels).

[Honzab-moz (honzab-moz)]

Sorry I didn't ask you in person first :) Thanks for reference to that bug, it might be useful for me to check my approach.

[Honzab-moz (honzab-moz)]

(From update of attachment 326390)
Changing back to Christian. As I read the patches in bug 265780 and as I know the code there is interface with method to provide async prompting but it is not implemented nor used and I am not sure if it were it would solve this bug.

[Druid (3-launchpad-fastdruid-co-uk)]

Another disagreement with the importance of "low", this is for me a "I can't use firefox" level bug.

If you're used to using tabs and are in a corporate environment with a passworded proxy firefox 3 is all but unusable due to the number of prompts for proxy passwords every time it starts. The first time I filled them in, the second time I started to get annoyed, the third time I thought "f*** it" and installed Opera instead.

Firefox 2.0.0.17 doesn't do this and purely because of this I haven't upgraded to firefox 3 from 2 on my windows box and won't until this is fixed.

Opera (which I swiched to *BECAUSE OF THIS BUG*) also prompts for proxy username and password for each page but both allows you to save the details and will close *all* the prompts when you click OK on the first.

[Matti-mversen (matti-mversen)]

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

[zorzella (zorzella)]

I hope it's not inappropriate to make an "out of the box" remark in this bug, but other browsers use OS's native mechanisms to encrypt data (DPAPI on Windows, Keychain on Mac, keyring on Gnome etc), obviating the need for a separate "master password" feature (and making bugs like this moot). Is there any reason why Firefox wouldn't want to move in this direction? Is there any current work being done in this regard?

[Shadowbottle (shadowbottle)]

Luiz-Otavio - Firefox would then lose its profile portability between platforms. It would be good to use native mechanism in /conjunction/, but not solely. Portability is an important feature of Firefox in general.
There are probably better reasons but that's what comes to mind immediately.
$0.02

[oneguycoding (steeve-oneguycoding)]

I just want to pipe up and say that I still see multiple master password prompts with FF 3.1b2pre. The cause seems to be related to the network sync feature of the reminderfox extension which stores its network password in the password database. If I disable the extension, I don't see the second master password dialog. If I enable the extension, I see two master password dialogs, and the frustration of having to enter the password in two dialogs fighting for keyboard focus. So it seems that the mitigation of the problem between restored session tabs has been solved, but not when extensions cause a password prompt.

[Laksiri-sampath (laksiri-sampath)]

early marked this as bug 369963

[John Vivirito (gnomefreak)]

This is not a firefox issue but an XULrunner issue, most likely this fix will only land in 1.9 branch

[TheQuickBrownFox (theprash)]

There should not be any master password dialog at all. Just a sliding bar at the top of the page like with the new remember password behaviour. See bug 461455

[Patoche-smart+mozilla (patoche-smart+mozilla)]

Installing Tab Mix Plus seems a good workaround for this bug.
https://addons.mozilla.org/firefox/addon/1122

[Shadowbottle (shadowbottle)]

@Patrick - except for the twenty bugs that TMP creates after installing. Not a very good workaround in my book.

[A-c-li (a-c-li)]

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

[Profiart (profiart)]

Passiert hier noch mal irgendwas, oder interessiert dieser Bug die Mozilla-Entwickler wirklich nicht?

[Eddy-nigg (eddy-nigg)]

Ich nehme an dass Du in Deutsch keine Antworten bekommst...

This bug has a blocking flag for FF 3.1.

[Cbook (cbook)]

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

[Zeniko (zeniko)]

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

[A-c-li (a-c-li)]

(In reply to comment #87)
> Niels, there's app-modal and window-modal. We don't want these dialogs to be
> app-modal.

Just curious: What's the difference w.r.t. this bug? When the password prompt appears it blocks all windows anyway (sometimes with the frustrating effect that you can't even see the prompt but it blocks even the maximize/minimize buttons of all other windows), and it frequently appears on the wrong monitor (in a dual-monitor setup).

IMHO if this were app-modal it would be at least less confusing.

[Matti-mversen (matti-mversen)]

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

[Dstavert (dstavert)]

Could the prompt for Master Password not happen before Firefox is fully launched. There is a mechanism for looking for updates during FF launch. It might then obviate the need to modify other dependent code????

[O-e-ekker (o-e-ekker)]

(In reply to comment #25)
> Could the prompt for Master Password not happen before Firefox is fully
> launched. There is a mechanism for looking for updates during FF launch. It
> might then obviate the need to modify other dependent code????

With FIPS enabled, FX3 needs the master password for checking for updates anyway, because it needs the master password before accessing a secure https website.

[Htamas (htamas)]

(In reply to comment #25)
If the user has set an expiry timeout for his master password, even asking it before Firefox starts is not enough. Having said that, I've implemented this functionality as an extension: https://addons.mozilla.org/en-US/firefox/addon/9808 .

[Dstavert (dstavert)]

You are correct about the timeout. I had a very short timeout and had to disable the timeout otherwise FF was totally unusable.

Just tried to apply the extension however it fails to install. "invalid hash file"

Thanks

[Htamas (htamas)]

(In reply to comment #28)
> Just tried to apply the extension however it fails to install. "invalid hash
> file"

Strange. I've tried installing it using several different configurations (computer, os, firefox version and language) and found no problem.

Are you able to install other (experimental) extensions from AMO?
Does anyone else have the same problem?

You could also have a look here:
http://kb.mozillazine.org/Unable_to_install_themes_or_extensions_-_Firefox#Invalid_file_hash

[Dstavert (dstavert)]

I made several attempts at logging in to clarify but got distracted. I can't install downloading and installing straight into FF. I get the "invalid hash error". I can install it if I download using IE and doing a file open. Tried with two different Windows machines. Same problem. I will try a couple of others. Could be the combination of addons??

The invalid hash link in your post looks to apply to FF 2 not 3 but what do I know.

FF Linux I have no trouble.

All that said the extension seems to work well although I haven't tried enabling timeout. I also tried several times to comment on the addons website and got distracted. I seem to have problems concentrating ;)

I'll let you know how my testing goes on other machines.

Thanks !!!

[Greg Whiteley (greg-whiteley)]

(In reply to comment #30)
> I made several attempts at logging in to clarify but got distracted. I can't
> install downloading and installing straight into FF. I get the "invalid hash
> error".

See bug 437174. Disabling third-party cookies prevents your AMO session details being provided by the XPI installer, so the download doesn't contain XPI data as expected.

Add a cookie exception to allow for addons.mozilla.org to workaround.

[Dstavert (dstavert)]

Done and that was the issue.

[Dstavert (dstavert)]

This addon seems to totally take care of the multiple master password prompt at FF startup. Other issues may arise when a master password expires (using the expire master password addon) and logged in pages expire and also regularly refresh. At any rate great work.

[G.J. Sterenborg (gevoelig)]

I can confirm this and agree with the rest.

Would be nice to have it fixed.

John or others, is there an XULrunner issue we can monitor?

[Jan Newmarch (jan-newmarch)]

Confirm that this is a nuisance for me too - I generally spend 10 minutes or so dismissing all the dialogues till I get home and can reload them rather than spend 1/2 hour entering all the uids and passwords required at work.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3) Gecko/2008101315 Ubuntu/8.10 (intrepid) Firefox/3.0.3

[billythegates (mfittko)]

I also confirm this bug and it is REALLY ANNOYING and should – in my opinion – be fixed ASAP. I am also a user who uses "more than one" tab at once in addition to the auto-restore function.

For me, the bug can be monitored since Firefox Version 1.5!

[G.J. Sterenborg (gevoelig)]

Found a link to (what appears to be) the bug on Bugzilla@Mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=460868

[G.J. Sterenborg (gevoelig)]

Correction.

The bug in the above link has a lot of similarities but it doesn't mention multiple tabs when launching firefox

[Matti-mversen (matti-mversen)]

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

[Dstavert (dstavert)]

I have been using this now for a while. I don't suppose that my usage is typical. I have literally hundreds of stored passwords. I use FF portable and my sessions travel with me. My browsing sessions may span weeks. I seldom ever open a fresh session. My current session is very light having just closed perhaps a dozen tabs. I am left with 12 tabs, half of which are logged in, including this one. Most of them expire in 20 minutes to half an hour. I use the master password timeout addon with a timeout of 5 minutes so I get frequent prompts. I may carry my portable drive to different computer several times a day. I mention all this to support that this addon seems to absolutely fix the problem. I get a single prompt prior to FF launch instead of, if this session were restarted, 6 prompts, none of which would actually work.
This an old bug. Hubai Tamas seems to have corrected it. Unless there are some things that it causes problems for IMHO it should be considered as a built in fix.

Thanks Hubai

[Alexander Sack (asac)]

On Wed, Dec 03, 2008 at 09:42:36PM -0000, G.J. Sterenborg wrote:
> Correction.
>
> The bug in the above link has a lot of similarities but it doesn't
> mention multiple tabs when launching firefox
>

I think we already have another bug in launchpad for this ... and that
is - iirc - also linked upstream.

 - Alexander

[Zeniko (zeniko)]

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

[A-c-li (a-c-li)]

Yes, this should have been app-modal all along; making it window-modal doesn't work. There is no advantage at all making it windows-modal.

I just spent minutes figuring out why Firefox stopped responding. It took MacOS X's F10 key to figure out that one of the Firefox's windows is requesting the master password for no reason. This is a serious usability bug.

[Shadowbottle (shadowbottle)]

(In reply to comment #173)
> Yes, this should have been app-modal all along; making it window-modal doesn't
> work. There is no advantage at all making it windows-modal.
>
> I just spent minutes figuring out why Firefox stopped responding. It took MacOS
> X's F10 key to figure out that one of the Firefox's windows is requesting the
> master password for no reason. This is a serious usability bug.

It doesn't seem to be consistent for me. I've had times where the prompt does /not/ reveal itself using show all windows in OS X and just wind up having to quit out of firefox completely and restarting. It's awesome.

[Mozilla-m (mozilla-m)]

This bug has gotten worse with 3.0.5 as it made the browser stack on Windows XP with the browser window blinking furiously as it gets and looses focus. My scenario involved multiple opened tabs.

[Honzab-moz (honzab-moz)]

I will soon create a test build including these patches and provide links to those builds here, for all platforms. Let's see if it helps or not. If yes I have to find someone to review or, at least, make comment on the two patches if those are or are not acceptable.

[Georges (georgeskesseler)]

I tried the addon it works for the master password.
No more prompts for the extensions.
But I still got multiple "proxy auth" prompts later when all the session tabs openend.
Note that my proxy has the extensions URL configured without proxy password but several of the tabs needed proxy password.

Still the addon helps get rid of about 30 dialogs which is quite a progress.

[Highmind63 (highmind63)]

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

[Matti-mversen (matti-mversen)]

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

[Htamas (htamas)]

Have you tried the AutoAuth addon for the proxy dialogs?
https://addons.mozilla.org/en-US/firefox/addon/4949

[Jamesrome-alum (jamesrome-alum)]

I just added AotuAuth to the 3.1 beta 2 on OS X. Now I get an uncaptioned password box when I start Firefox. I presume that is for my master password. Or, it could be a piece of malware trying o steal my credentials......

[Me-taupehat (me-taupehat)]

Voted on this. I not only have to enter the prompt for every password-protected tab I had open when I last closed the session (most of them - intranet stuff while at work), but also for the proxy server.

IMO, this is not the sort of bug that should be resolved by installing an extension. Given the age of this bug, I'm a bit concerned that it's been left "UNRESOLVED DONTCARE"

[Wildmyron (wildmyron)]

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

[Kai Engert (kaie)]

Honza? I seem to remember you intended to look at a related bug, but I might be wrong. Do you have thoughts about the attached patch?

[Kai Engert (kaie)]

Ok, I now understand that I must review bug 348997 first.

[Kai Engert (kaie)]

Created an attachment (id=354586)
Same as earlier "Improovment to prompt service"

This is the same as attachment 326390, but with the equivalent of "diff -p" added, plus some more context.

[Kai Engert (kaie)]

Honza, could you please write a (short) comment that answers the question:
  "What is the purpose of class PromptAggregator and what mechanism
  does it use to achieve it?"
(and add that comment near the class definition)

Proposed test: Say you have two Firefox windows open. In one window you use "open group of tabs bookmark". This group of tab requires two different password prompts. With your patch one prompt is now queued. The first prompt comes up. Now you say "firefox quit" in the other window. What will happen? When the first prompt gets closed, will your new code open the second prompt window and block exit?

[Kai Engert (kaie)]

You declare and unlock mUserAndPasswordPromptAggregator, but you never seem to use it. I guess you had intended to use it in function nsPromptService::PromptUsernameAndPasswo...

[Kai Engert (kaie)]

I think it could help understanding the code if you rename
mPasswordPromptAggregator => mTrackActivePasswordPrompt
mUserAndPasswordPromptAggregator => mTrackActiveUserAndPasswordPrompt
mTopAggregator => mActivePromptTracker

In function UnlockAggregator, please explain in a comment the purpose of your comparisons/tests.

+ while ((*mTopAggregator)->mLocked) {
+ if (!NS_ProcessNextEvent(thread))
+ return PR_FALSE;

I'm worried that you use a plain bool variable and this loop.
Is it guaranteed that "wake up after unlock" will always happen?

[Kai Engert (kaie)]

 nsPromptService::DoDialog(nsIDOMWindow *aParent,
- nsIDialogParamBlock *aParamBlock, const char *aChromeURL)
+ nsIDialogParamBlock *aParamBlock, const char *aChromeURL,
+ void **aAggregator)

I'd rename new parameter aAggregator to something like
  aPromptSingletonTracker

I'd rename WaitAndGrab to something like SingletonWaitAndGrab, because you don't wait (and don't grab) if the current prompt is not a singleton prompt (no singleton tracker was provided).

Could it happen that you two threads "race" for the same prompt to get opened?
You don't have synchronization objects (mutex/lock) that would prevent it.
This would probably require that your mPasswordPromptAggregator and mUserAndPasswordPromptAggregator aren't just pointers, but each would have to be an object containing a lock and the pointer.

Or maybe, even better, make PromptAggregator an object containing a lock, create two instances for your 2 singleton trackers.

typo "neccesarry" => necessary

[Kai Engert (kaie)]

Your function CheckString leaks.
nsDialogParamBlock::GetString returns you a new copy of the string, so you must destroy it after you're finished comparing.

+ // We don't need to create a private copy because the
+ // param lives on lower stack frame.

I think GetString already gave you a private copy.

[Honzab-moz (honzab-moz)]

Kai thanks for looking at this. To answer:

- What the PromptAggregator class is for:
Each instance of that class is bound to each prompt request. The first instance (and therefor the first prompt request with it) is saved in the mPasswordPromptAggregator member pointer. Any other instance (so, any other prompt request) checks that member is non-null, if so, it spins the event loop and waits for the first dialog to finish (WaitAndGrab method). After it is finished (the first prompt's chrome window has been unregistered) the class gets (grabs) return values (e.g. entered credentials) from the first dialog param block and immediately leaves without invoking the same dialog again.

- The test with few tabs and another window:
I tired that (on win machine). It doesn't pop-up another dialog after the first one is closed. But w/o this patch when I quit from the other window, all dialogs are closed and Firefox quits w/o waiting for dialogs to be closed by user, immediately. With this patch it waits for the prompt. We could override this by handling also some of the "quit" observer events to wake up the aggregates.

- mUserAndPasswordPromptAggregator never used:
Leftover, we can have one member for each type of a prompt or use one member to block/stack all types of dialogs.

- Wake up after unlock:
We could potentially unlock other aggregates by an event posted to the main thread from "domwindowclosed" observer event. True is we don't guarantee in any way to loop the spin. It is just highly probable it will loop.

- Multi-threading:
It seems nsPromptService is not designed as to be thread safe at all. As I've seen the code it is always used through a proxy where invoked from other threads. So I would not bother with any locks.

- GetString returns a copy:
Good catch, I wasn't aware of that. Have to release it.

I'll create a patch with fixes you propose, and with larger context.

[Timeless-bemail (timeless-bemail)]

> If this is about a race for SDR, don't we need a lock to protect the mBusy
state?
> Are multiple calls to SDR originate from multiple threads, or from event
processing on a single thread?

> NS_IMPL_ISUPPORTS1(nsSDRContext, nsIInterfaceRequestor)

since the code isn't threadsafe, no lock is required. the only issue is reentrancy. so yes, this is from a single thread.

[Highmind63 (highmind63)]

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

[Honzab-moz (honzab-moz)]

- The test with few tabs and another window, again:
Kai, I retested ones again, and you were right. I didn't notice before that it is really a secondary dialog appearing after quit. I'll try to find a way to fix that. If I won't find we'll probably have to move to a different approach, probably async prompt capability.

[Kai Engert (kaie)]

(From update of attachment 329486)
Please re-request reviews when you have new patches, removing review request. And you might want to mark patches as obsolete.

[oneguycoding (steeve-oneguycoding)]

Question, are these changes going into the Shiretoko nightly builds?

[Honzab-moz (honzab-moz)]

The 'Improovment to prompt service' patch approach seems to be wrong because of found problem during shutdown that Kai pointed out in comment 180. I don't know how to fix that in simple and safe way, so I need to let my brain process that at the background to come with something better. Probably implementing and integrating async prompts would be the way...

[Honzab-moz (honzab-moz)]

(From update of attachment 326390)
Approach of this patch is wrong.

[Cartier-b (cartier-b)]

Clearly this is a usability bug. It is a security risk in that if a person gets conditioned to entering his master password into a lot of dialog boxes a malicious app could throw up a similar dialog.

I agree with Mike that this is core functionality that cannot be trusted to a plugin.
I applaud Hubai for writing the plugin, but I don't know anything about him and am not about to risk my master password.

[Erisks (erisks)]

Created an attachment (id=355730)
screenshot after installing 3.0.5 (Win)

as you can see, you caint see nuthin

this is windows, behind a proxy that requires AUTH
but the experience is similar at home, OSX, no proxy:
there is at least one master password prompt per open tab,
and they block each other out.

[gero (gerod)]

Bug 177175 is a duplicate, started 2002-10-28...

[gero (gerod)]

This bug is a duplicate of bug 348997. This one was started earlier, but the other one has more info and more visibility: Currently 193 comments, 109 users CC'ed, and 74 votes.

[Highmind63 (highmind63)]

(In reply to comment #40)

Not really a dupe per se, bug 348997 is a regression, this bug is not AFAICT. The bug there is about session restore where as this one is not. The patch there will probably fix this, adding dependency.

[Dstavert (dstavert)]

I was not suggesting that the plugin be the fix but that the prompting for the master password prior to FF launching seems to solve the multiple master password prompts.

[Dstavert (dstavert)]

I originally asked the question as to whether launching the master password prompt prior to FF starting could be a place to start a fix. While Hubai's plugin has made FF usable for me, Brian does have a point that it shouldn't be left to a plugin. I would like to ask if this might be a rather large security hole that it is even possible to launch the master password prompt or tie in to the FF security at all. I use Sxipper, the master password timeout as well as the Hubai plugins. I guess I could be in trouble couldn't I.

[Georges (georgeskesseler)]

I hope that when this is fixed all verious possibilities will be handled.
So in my case I have:
* passwords inside webpages triggering master password prompts
* basic auth websites dialog boxes
* proxy auth dialog boxes
And combinations of those :-)

I installed a plugin which asks for the MP in advance. It makes the situation a bit better. I now only get lots of proxy auth dialogs which are prefilled and I can click 20 times on OK to get going. At least I don't have to fill in the master password 20 times.
Perfect solution would be that there's only one single password prompt (be it basic, proxy or MP) at any time. And it should be forced to front as in FF2 it sometimes happened that the dialog was hiding behind some window.

Thanks for your work on this!

[Ralf-wohner (ralf-wohner)]

(In reply to comment #194)
> I installed a plugin which asks for the MP in advance.
> It makes the situation a bit better. I now only get
> lots of proxy auth dialogs which are prefilled and I
> can click 20 times on OK to get going.
May I ask, which plugin? Today I had 30 MP prompts :-) I'm getting nuts just starting Shiretoko. I'm using it as a programmer in our intranet and always have 20-30 bug tabs open and gladly use session restore to have them open at the next start. But every such tab triggers a MP prompt.

> At least I don't have to fill in the
> master password 20 times.
Neither do I. I found that I can just press enter/OK at every MP prompt except for the first one (=the last that opened, as it blocks all others). But I think such a plugin/addon would prevent the other 29 from opening.

Praying for a fast solution (except for going back to 2.0)
Ralf
(Mandriva Linux 2008-2009, various PCs)

[oneguycoding (steeve-oneguycoding)]

I installed this plugin yesterday, it's called StartupMaster. This approach, of course, would have been the trivial configuration tweak to save us all months of pain and anguish. Rant off. :)

[Profiart (profiart)]

Thank you steeve. The StartupMaster Addon fix a problem what no one of the Firefox programmers was able to fix for many months.

[Nelson-bolyard (nelson-bolyard)]

The fact that the browser developers let this bug persist for so long tells
me that the browser developers do not experience that problem themselves.
That says to me that there is some aspect of this bug upon which they do
not depend. The question is: what aspect is that? Is it that they do not
use saved groups of tabs? Or is it that they do not use a master password?
Whatever it is, you can be sure that the quality of that feature will not
improve significantly while they don't use it.

[Daniel Thompson (daniel-thompson)]

(In reply to comment #198)
> The fact that the browser developers let this bug persist for so long tells
> me that the browser developers do not experience that problem themselves.
> That says to me that there is some aspect of this bug upon which they do
> not depend. The question is: what aspect is that?

It is not 'normal' to require a password on every tab that opens. Thus this bug
already describes an unusual case. Likewise it is not very common for people to
enable the master password feature. I think this combined makes this problem
fairly unusual.

The combination that makes this problem especially inconvenient is typically
something like:

a) a corporate firewall that requires a password
b) setting a master password so that one else can (easily) send your firewall
   login (which can be a useful job protection measure).

In this circumstance *every* tab whether the site behind it requires a login or
not demands a password (i.e. 10 tabs means *twenty* dialogs, 10 for the master
password and 10 for the firewall login).

[Hskupin (hskupin)]

Nelson, I have the same problem for a couple of month and it's really easy to reproduce. It would be great, if we could fix this bug soonish. It annoys me each time I have to restart the browser. Today I've also installed the mentioned addon and it works perfectly. I believe the attached patches will do the same...

So, we have two patches attached to this bug. Honza and Kaie, which of those patches need review? Or which of these patches will be the better one? It would be nice to save some time for biesi before he starts to review the wrong patch.

[Honzab-moz (honzab-moz)]

Created an attachment (id=356180)
v2.1 - http channel async prompting

Henric: THIS particular patch is simple and relatively safe solution to this problem. It modifies a way how http channel handles prompts for username and password. With this patch there are no more two credential prompts for a single page or a proxy server.

Christian: this is patch with large context and methods and explanatory comment in nsHttpChannel::GetCredentialsForChallenge. It could be considered as base for implementation of async prompts (bug 265780).

[Novashadow (novashadow)]

OK, I did some more digging and found that WebMail Notifier 1.1.7 by Byungwook Kang is the major cause of my issue. I will let him know. It caused me to get tons of master password requests. Without this add-on, I usually (90% to 95%) get asked for my master password twice and the rest just once. I performed this test with 4 windows and 27 tabs between them and at the end I have 22 add-ons enabled. I love Firefox 3 as it's still fast and stable with all of them.

Now I have done this before and all can say is that maybe I was not as through as i was this time, which may be true in one way or another, and/or multiple add-ons caused this issue before that have now removed that problem so enabling a few at a time, rather than one at a time kept the issue making me think it was a Firefox issue and not an add-on issue.

I do like the idea of the way that StartupMaster does this in that it asks for the password before showing Firefox windows and if the person does not know that password or clicks cancel, you do not loose your session data. I think the only way to get out of this with our StartupMaster if you do not know the password is to kill the Firefox process.

The following is not directly related to this topic, but I am not sure where to put it. If it makes you mad, ignore it or weather it does or does not, you could direct me to the proper place where it will likely be reviewed and/or to some good add-ons for dealing with sessions, session recovery and tabs.

The point for me using the master password tab it 2 fold.
1) Protect my accounts on site for which I have saved passwords.
2) Protect my sessions, which it does not so all the time, see my suggestion/request above about StartupMaster.

This leads me to think about some issues with the whole save and restore session process. I understand that this is relatively new, but it has some great uses which is why people want it, but currently, it is easy to totally screw it up and there are no easy tools to fix or undo a mistake which could take a use a while to recover from and there is a huge lack of consistency. e.g. You have to have turn on the option "warn me before closing multiple tabs" for any of this to work which is inconsistent because I could have 2 windows with one page each and it would ask me to save and quit with this option, but there is no way to get that message without this option on.

[Novashadow (novashadow)]

This is a version of my post with better grammar and clarity.

OK, I did some more digging and found that WebMail Notifier 1.1.7 by Byungwook Kang is the major cause of my issue. I will let him know. It caused me to get tons of master password requests. Without this add-on, I usually (90% to 95%) get asked for my master password twice and the rest just once. I performed this test with 4 windows and 27 tabs between them and at the end I have 22 add-ons enabled. I love Firefox 3 as it's still fast and stable with all of them.

Now I have done this before and all can say is that maybe I was not as through as I was this time, which may be true in one way or another, and/or multiple add-ons caused this issue before. This would mean that all the add-ons that I have except WebMail Notifier 1.1.7 have fixed this issue, so enabling a few at a time, rather than one at a time, kept returning this issue making me think it was a Firefox issue and not an add-on issue.

I do like the idea of the way that StartupMaster does this in that it asks for the password before showing Firefox windows and if the person does not know that password or clicks cancel, session data is not lost. I think the only way to get out of this without StartupMaster if you do not know the password is to kill the Firefox process.

The following is not directly related to this topic, but I am not sure where to post it. If it makes you mad, ignore it. Weather it does or does not, you could redirect these suggestions/requests or direct me to the proper place where they will likely be reviewed and/or to some good add-ons for dealing with sessions, session recovery and tabs.

The point for me using the master password tab it 2 fold.
1) Protect my accounts on sites for which I have saved passwords.
2) Protect my sessions, which it does not so all the time, see my suggestion/request above about StartupMaster.

This leads me to think about some issues with the whole save and restore session process. I understand that this is relatively new, but it has some great uses which are why people want this feature. Currently it is easy to totally screw it up and there are no easy tools to fix or undo a mistake which could take a user a while to recover from and there is a huge lack of consistency. e.g. You have to have turn on the option "warn me before closing multiple tabs" for any of this to work which is inconsistent because I could have 2 windows with one page each and it would ask me to save and quit with the referenced option on, but there is no way to get that message without the referenced option on.

[Matt Fischer (mfisch)]

Still happening for me with 3.0.5 and seems to be caused by my gmail add-in which authenticates immediately on start-up. For me, typing the password in the first couple of times results in a failure (I assume) and then field then partially clears itself, only partially mind you.

[Olivier Kaloudoff (kalou)]

FYI,

   this bug does not happens with Debian lenny, Iceweasel 3.0.5, Mozilla 5.0, rv 1.9.0.5, Gecko 2008122011

    hope this helps

Olivier

[Christian Biesinger (cbiesinger)]

(In reply to comment #201)
> Christian: this is patch with large context and methods and explanatory comment
> in nsHttpChannel::GetCredentialsForChallenge. It could be considered as base
> for implementation of async prompts (bug 265780).

Wouldn't a lot of it go away with async prompts (and move to the windowwatcher or something)?

[Christian Biesinger (cbiesinger)]

(From update of attachment 356180)

This patch is complicated enough that it really needs test.

--
>+ , mAuthRetryAsync(PR_FALSE)

I'm not sure what the point of this variable is. You only check it in OnCredentialsAcquired, and when would that be called with mAuthRetryAsync == PR_FALSE?

>+ if (NS_ERROR_IN_PROGRESS == rv) {

Style in this file is generally the other way round:
  if (rv == NS_ERROR_IN_PROGRESS)

>+ mAuthRetryAsync = PR_TRUE;
>+ return Suspend();

So, this means that cancelling a channel while it's waiting for an auth prompt does not immediately cancel it. That seems unfortunate. Can you find a fix that doesn't require suspending the channel?

>+ else if (NS_ERROR_IN_PROGRESS == rv)
>+ return rv;

Same style comment as above.

>+ nsRefPtr<nsHttpHandler::PromptForIdentityLock> promptLock;

Don't really see why this has to be refcounted...

>+ /*
>+ gHttpHandler keeps a hash table of prompt tracks ('locks') for

Multiline comment style in this file is using C++ comments, i.e. a // on each line.

>+ each "realm | authType".

Why just for each realm + authType, why not also hostname?

I also note that this will do nothing to fix the master PW problem mentioned in the bug. If you have two URLs with different realms you still have the problem, right?

>+ is still open (awating user input) it is not allowed to popup

awating -> awaiting

>+ if (promptLock)
>+ promptLock->CredentialsAcquired(rv);

I know it's not strictly necessary to call this when the user cancelled the dialog, but it may still be better to preserve the original error code.

>diff --git a/netwerk/protocol/http/src/nsHttpHandler.cpp b/netwerk/protocol/http/src/nsHttpHandler.cpp
>--- a/netwerk/protocol/http/src/nsHttpHandler.cpp
>+++ b/netwerk/protocol/http/src/nsHttpHandler.cpp
>+ nsCAutoString key(aRealm);
>+ key.AppendLiteral("|");

key.Append('|');

>+ key.Append(aAuthType);

>diff --git a/netwerk/protocol/http/src/nsHttpHandler.h b/netwerk/protocol/http/src/nsHttpHandler.h
>--- a/netwerk/protocol/http/src/nsHttpHandler.h
>+++ b/netwerk/protocol/http/src/nsHttpHandler.h
>@@ -42,36 +42,40 @@
>+#include "nsHashKeys.h"
>+#include "nsBaseHashtable.h"

Shouldn't you instead use nsClassHashtable? As in:

  nsClassHashtable<nsCStringHashKey, PromptForIdentityLock>

>+ class PromptForIdentityLock : public nsISupports

I think this would be simpler if you notified the channels in CredentialsReceived instead of in the destructor.

Why did you derive this from nsISupports? I don't really see what advantages the refcounting gives you here, and you don't care about QI either.

And why the split between this and PromptForIdentityLockInternal?

Also, classes should be declared at the beginning of a public/protected/internal section, not in the middle of functions.

+ nsCOMArray<nsIHttpChannel> mChannels;

Why not use an array of nsHttpChannel instead? As in nsTArray<nsRefPtr<nsHttpChannel> >, although I don't see why this can't be nsTArray<nsHttpChannel*>.

>+ typedef nsBaseHashtable<nsCStringHashKey, PromptForIdentityLockInternal*, PromptFor...

[oneguycoding (steeve-oneguycoding)]

Not sure what the style guidelines suggest for mozilla apps, but this approach,

>+ if (NS_ERROR_IN_PROGRESS == rv) {

catches this error during compilation,

if (NS_ERROR_IN_PROGRESS = rv)

[ZTiger (daniel-ztiger)]

I would like to confirm this issue as well. As a work around I have NTLMAPS (http://sourceforge.net/projects/ntlmaps/) running and it seems to work running through that proxy. However the proxy of a proxy is not my ideal of a fix. If Mozilla or Canonical have any sway with the XULrunner folks, it would be much appreciated to have this fixed soon.

NOTE: I do not see this issue on my windows system. That maybe because I have the NTLM pass through enabled so that the windows credentials are passed to the proxy requests.

[Kai Engert (kaie)]

I agree that comparisons like
  if (NS_ERROR_IN_PROGRESS == rv)
are a good idea, as they avoid typos and accidental assignments, it's an old trick, I personally wouldn't reject such code.

[Highmind63 (highmind63)]

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

[marcobra (Marco Braida) (marcobra)]

http://forums.mozillazine.org/viewtopic.php?f=8&t=326089

I think there is no need to see proxy login dialog at startup when there is a remembered user/pwd by the password system.

The dialog must be showed only when no user/pwd are stored or login to proxy is not ok.

I don't know if there is a tunable about:config parameter to do this.

When FF is started some little graphics can notify to the user the direct or proxyed connection type.

Go Firefox

[Christian Biesinger (cbiesinger)]

I know what the purpose of that style is. But it's not the style that this file uses.

[Gavin Sharp (gavin-sharp)]

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

[Digulla-hepe (digulla-hepe)]

Just an idea: How about you only show these dialogs if the current visible tab needs it?

For all hidden/inactive tabs, suppress the dialog and set a flag in the tab to display the dialog only when the tab becomes active. At that time, you should check again whether the password has been set.

[jpfle (jpfle)]

(In reply to comment #43)
> and yes, it's generally for anything requiring master password, and you may see
> an amusing screenshot in Bug 456427 ;)

To tell the truth, I don't think the screenshot at https://bugzilla.mozilla.org/attachment.cgi?id=339825 is amusing. This bug is open since 2006, there are 46 votes, 50 comments, 60 cc, and its status is still NEW.

This bug is more than annoying. Having dozens of password prompts makes Firefox near unusable.

[A-c-li (a-c-li)]

(In reply to comment #209)
> I know what the purpose of that style is. But it's not the style that this file
> uses.

If the point of the style is to catch typos, shouldn't the rest of the code be rewritten using this style instead, if this is not the style that this file uses?

[Beltzner (beltzner)]

We're not going to block on this issue, but please do not take that as a statement of disinterest in terms of fixing it.

At 200+ comments, it's nigh impossible for me to get a good sense of what's causing this bug. It's related to session restore, I see, and to having a master password, but the solution being proposed seems to be deep within the networking voodoo. Can we not just do something to the session restore code that looks like:

 - check to see if the profile has a master password
 - if it does, ask the user for their password before restoring the session

cc'ing Johnath, as making the Master Password stuff better is very much going to be his bailiwick.

[Zeniko (zeniko)]

(In reply to comment #211)
> - check to see if the profile has a master password
> - if it does, ask the user for their password before restoring the session

I strongly oppose such a solution if we don't know in what situations the master password is actually going to be required (AFAICT it's mostly related to proxies, HTTP basic auth and secure sites where we don't save cookies). Without a more fine-grained wall-paper patch, this might well make the master password feature unusable for people who've set Firefox to "Show [all] windows and tabs from last time".

Secondly, you also get multiple prompts without a master password set, and we couldn't work around those inside SessionStore.

Finally: Adjusting the summary to indicate that this isn't Session Restore specific at all (that seems just the most common situation in which this issue arises).

[Dolske (dolske)]

The basic cause of this (and all the similar related bugs) is that there was never any code to explicitly check/prevent multiple prompts. Things just relied on the prompt blocking *everything* (ie, one tab prompts for something, every other tab freezes). Thus you'd only get one prompt at a time, and that also prevented getting repeated prompts for the same login.

Thread manager came along in 1.9, removed the blocking behavior (highly desirable for other reasons), and no one realized the complexity of the problem until it was too late to safely deal with it.

Multiple master-password prompts are one symptom of this problem, and could perhaps be wallpapered over by forcing a prompt before anything starts loading... Except that would mean you'd *always* get a MP prompt, even if the restored session wouldn't normally need to prompt. Such wallpaper also wouldn't help with the specific flavor of this bug, in that you'd still get multiple prompts for the same HTTP auth (and proxy auth).

[Shadowbottle (shadowbottle)]

(In reply to comment #213)
 > Multiple master-password prompts are one symptom of this problem, and could
> perhaps be wallpapered over by forcing a prompt before anything starts
> loading... Except that would mean you'd *always* get a MP prompt, even if the
> restored session wouldn't normally need to prompt. Such wallpaper also wouldn't
> help with the specific flavor of this bug, in that you'd still get multiple
> prompts for the same HTTP auth (and proxy auth).

I'm confused, if it could "perhaps be wallpapered over by forcing a prompt before anything starts loading..." but "you'd still get multiple prompts for the same.." then how does it wallpaper it?

I'm absolutely fine with launching firefox and getting a pw prompt before any other windows opening - that actually sounds ideal. If the person launching that profile doesn't have the password then they can't even see what tabs you have open. At this point anything besides dozens of password prompts sounds terrific. Let's do that.

[Dolske (dolske)]

(In reply to comment #214)

> I'm confused, if it could "perhaps be wallpapered over by forcing a prompt
> before anything starts loading..." but "you'd still get multiple prompts for
> the same.." then how does it wallpaper it?

It would wallpaper over the multiple master-password prompt (which isn't what this bug is about), but not multiple for HTTP-auth or proxy-auth.

> If the person launching
> that profile doesn't have the password then they can't even see what tabs you
> have open.

Yes they can. That's not what the master password protects.

[Shadowbottle (shadowbottle)]

(In reply to comment #215)
> (In reply to comment #214)
>
> > I'm confused, if it could "perhaps be wallpapered over by forcing a prompt
> > before anything starts loading..." but "you'd still get multiple prompts for
> > the same.." then how does it wallpaper it?
>
> It would wallpaper over the multiple master-password prompt (which isn't what
> this bug is about), but not multiple for HTTP-auth or proxy-auth.
>
> > If the person launching
> > that profile doesn't have the password then they can't even see what tabs you
> > have open.
>
> Yes they can. That's not what the master password protects.

Sorry, that should have been future tense. As in "Should there be a prompt for password before loading /any/ other windows, then it would be ideal. At such a point the person attempting to launch the browser <would then be presented with only a password prompt> would not be able to even see any of the tabs that were being restored from the previous session". Hope that clarifies my post.

[Niels-keurentjes (niels-keurentjes)]

(In reply to comment #215)
> Yes they can. That's not what the master password protects.

Perhaps it would be a great short-circuit to this whole discussion - make the master password a true master password that doesn't just protect passwords but also the user's tabs, browsing history and settings.

[Mozbug1 (mozbug1)]

That is not a true solution. Some of us don't want to use master passwords, or store our passwords at all, but don't want to have to type in our username/password multiple times when opening a multi tab bookmark.

[Niels-keurentjes (niels-keurentjes)]

Then you don't configure a master password, as you would now? I'm not suggesting the master password should be mandatory, just to solve a messy problem by making it a tad more encompassing for those who choose to use it. It seems a strange luxury to postpone the master password test until you run into the first protected site *and then remember it*. If you remember it, might as well ask for it at the start of the session.

[Dpeelen (dpeelen)]

The master password is used to encrypt and protect the passwords. I use it especially for that. I don't mind other's browsing the web from my computer, as long as they stay away from my passwords. For this i even have a extension that reset the master password after 5 minutes, so i can safely walk away from my computer.

Also, if you want to protect the entire profile behind the master password, you would also need to encrypt all the session data and possibly bookmarks/history and everything else. Doesn't look like a simple or easy workaround to me.

Beside, the problem is wider then only the master password pop-up, but also multiply (pre-filled) login popups for the same site, or proxies passwords etc. Would make more sense to solve the underlying problem. Didn't the current patch get a long way in that direction?

[Georges (georgeskesseler)]

> It would wallpaper over the multiple master-password prompt (which isn't what
> this bug is about), but not multiple for HTTP-auth or proxy-auth.

I, as a normal firefox user, are perfectly happy with the wallpaper master password by using an extension doing exactly that. Later I get lots of prompts for http proxy auth and http auth but at least they are filled out and I can just happily press return. Not such a big deal. Whereas the master password pops up without a password filled in (obviously) and my tests showed that not filling it in every time correctly won't give you all the tabs logged in like you want.

Suggestion: add a toggle to the master password setting dialog for "require password for whole session" with the obvious problem that the session data (history, cookies...) is not really secret by using this password.

[Daniel Thompson (daniel-thompson)]

Allow me to describe a few use cases. I'll start with my own, where I know I'll get the current status dead on, and then move on to others outside my direct experience. Please correct current status if I make errors.

Daniel uses Firefox in a corporate environment with a password protected proxy, the password for which is encrypted with the master password. When opening multiple tabs without having authenticated yet (e.g. session restore or "Open All in Tabs") he expects to type his master password and (populated) proxy authentication dialog only once.

Current status: Daniel observes a master password and authentication dialog once
                for each tab (e.g. 10 tabs -> password must be typed 10 times,
                OK pressed 20 times)

Wallpaper-fix: Would reduce only the number of times the master password
                appears (e.g. 10 tabs -> password must be typed once, OK
                pressed 11 times). Nevertheless it would actually make Daniel
                quite happy since he would do much less typing (and dialogs
                would no longer key popping up and stealing the keyboard
                focus from the Master Password dialog).

Sharon uses Firefox at home and likes to use lots of password protected web sites, the passwords for which are encrypted with the master password. When opening multiple tabs without having authenticated yet (e.g. session restore or "Open All in Tabs") she expects to type her master password only once and for the (populated) proxy authentication dialogs to appears once for each tab (assuming each tab is a different site). (e.g. 10 tabs -> password types once, OK pressed 11 times).

Current status: Sharon observes a master password and authentication dialog once
                for each tab (e.g. 10 tabs -> password must be typed 10 times,
                OK pressed 20 times)

Wallpaper-fix: Would make Sharon very happy...

William uses Firefox and is very fastidious about security so he chooses to never store passwords. When opening multiple tabs to the *same* authenticated site (e.g. password protected mailing list archives) he expects to have to enter his credentials once only.

Current status: William observes an authentication dialog once tab in the same
                authenticated site.

Wallpaper-fix: Would make no difference to William.

I would suggest (without evidence) that Sharon's problems are the most important since they affect normal users in normal environments. Choosing between Daniel (unusual environment) and William (?unusually paranoid?) is more difficult and I have a clear prejudice...

For the record Daniel is currently using the StartupMaster add-on which is, in effect, the wallpaper-fix and is currently perfectly happy.

[Jdsmet (jdsmet)]

From reading the latest comments it seems that for some people, including me, it's enough to enter the master password in the first dialog that appears only, and just pressing enter without typing the password on the remaining master password dialogs, while for others things only work properly when typing the master password in ALL the dialogs.

Has anyone figured out what causes that disparity?

[Daniel Thompson (daniel-thompson)]

(In reply to comment #223)
> Has anyone figured out what causes that disparity?

Personally I'd missed these comments and it never occurred to me that I could enter no password and have things work.

[Brian J. Murrell (brian-interlinx)]

Maybe I am stating the obvious, and I have definitely not looked at the source, but from a code point of view, it seems to me that these various input routines need to be "global" in nature (in reference to all of the threads that multiple tabs create) and needs to function in such a manner, assuming a tab calls such a globally aware "get_password()" function:

char * get_password() {

    static int dialog_active = false;
    static char *password = NULL;

    if (password)
        return password;

    if (dialog_active)
        while (!password)
            sleep(1);
    else
        password = password_dialog();

    return password;

}

The spinloop on password is lame, I know, but I am sure somebody more familiar with the toolkit can come up with some form of non-spinning wait.

And of course, as always, the devil is in the details... :-)

[Mrlint+bugzilla (mrlint+bugzilla)]

(In reply to comment #225)

Brian,

Of course I know you aren't posting real code, but one thing I'd like to add is not only if the dialog is active, but if a dialog is active for the same credentials. For which possibilities can be reduced by inspecting the server and port asking for credentials.

> Maybe I am stating the obvious, and I have definitely not looked at the source,
> but from a code point of view, it seems to me that these various input routines
> need to be "global" in nature (in reference to all of the threads that multiple
> tabs create) and needs to function in such a manner, assuming a tab calls such
> a globally aware "get_password()" function:
>
> char * get_password() {
>
> static int dialog_active = false;
> static char *password = NULL;
>
> if (password)
> return password;
>
> if (dialog_active)
> while (!password)
> sleep(1);
> else
> password = password_dialog();
>
> return password;
>
> }
>
> The spinloop on password is lame, I know, but I am sure somebody more familiar
> with the toolkit can come up with some form of non-spinning wait.
>
> And of course, as always, the devil is in the details... :-)

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

(In reply to comment #225)

> if (dialog_active)
> while (!password)
> sleep(1);

Brian - there is already a working implementation of this approach in bug 475053.

[Matti-mversen (matti-mversen)]

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

[nonexistent account (nonexistentaccount)]

Confirmed also here with Kubuntu 8.10 and FF3.0.5.

Is there by any chance a way to integrate ff master password into KDE Wallet? Or is it just utopia due to ff being a GTK app?

[Louis-Dominique Dubeau (ldd)]

On Fri, 2009-02-06 at 12:28 +0000, piksi wrote:
> Is there by any chance a way to integrate ff master password into KDE
> Wallet? Or is it just utopia due to ff being a GTK app?

Whether or not it is utopia, integrating Firefox with the KDE wallet
should be a separate feature.

It is not the proper solution to the specific problem reported here.
Firefox should behave intelligently when multiple tabs needing
authentication are loaded at once. It does not need to use the KDE
wallet for this purpose.

[Alexander Sack (asac)]

On Fri, Feb 06, 2009 at 12:51:57PM -0000, Louis-Dominique Dubeau wrote:
> On Fri, 2009-02-06 at 12:28 +0000, piksi wrote:
> > Is there by any chance a way to integrate ff master password into KDE
> > Wallet? Or is it just utopia due to ff being a GTK app?
>
> Whether or not it is utopia, integrating Firefox with the KDE wallet
> should be a separate feature.
>
> It is not the proper solution to the specific problem reported here.
> Firefox should behave intelligently when multiple tabs needing
> authentication are loaded at once. It does not need to use the KDE
> wallet for this purpose.
>

FWIW, upstream bug is properly linked. In addition to that there is
related bug https://bugzilla.mozilla.org/show_bug.cgi?id=348997 which
is quite active still ...

 - Alexander

[Matti-mversen (matti-mversen)]

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

[Jerome-belos (jerome-belos)]

This is particularly irritating after add-ons updates: The add-ons windows opens after restart and keep asking for the master password (I have a proxy identification and login/pwd is stored).

Also, sometimes, you don't want to enter the master password, but even if you cancel the prompt, you'll be asked on the next page that will contain a stored login.

That would be nice if by cancelling the master password prompt, it would be reduced as a simple icon in the status bar so that you can call it back again when you want / need.

[Matti-mversen (matti-mversen)]

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

[John Vivirito (gnomefreak)]

This looks to be a dupe of bug 177175. Can this be confirmed and marked as needed please. Thanks

[John Vivirito (gnomefreak)]

This does look like bug 356097

[Vomito (vomito)]

Yes, it seems to be a dupe, since "proxy authentication" depends on "master password prompt" when you decide to save passwords.

[Honzab-moz (honzab-moz)]

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

[Honzab-moz (honzab-moz)]

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

[Plouj (plouj)]

Shouldn't this bug be marked as a duplicate of the more general and older bug 177175?

[John Vivirito (gnomefreak)]

This seems to have more info on it that the older bug.
Thanks for marking as duplicate

[John Vivirito (gnomefreak)]

Alexander please look at the following bugs as they look the same.

https://bugzilla.mozilla.org/show_bug.cgi?id=177175

https://bugzilla.mozilla.org/show_bug.cgi?id=356097

[Georges (georgeskesseler)]

For those being annoyed, there is a workaround in the now duped 177175. Not pretty but it does make life easier. https://bugzilla.mozilla.org/show_bug.cgi?id=177175#c36 which is in general an interesting read with several user experiences.

In some cases this plugin does not protect me against the extension updater displaying as many master passwords as there are plugins. Those show as empty dialogs, no text.

[Georges (georgeskesseler)]

(In reply to comment #58)
I linked to the wrong extension, so here is an even better workaround https://bugzilla.mozilla.org/show_bug.cgi?id=177175#c27 which is the one I am using now.

[Matti-mversen (matti-mversen)]

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

[Jo-hermans (jo-hermans)]

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

[longsonr (longsonr)]

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

[Timeless-bemail (timeless-bemail)]

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

[komputes (komputes)]

The following Firefox Add-on was developed to correct this exact problem. It fixes multiple master password prompt at resume by asking it at startup.

https://addons.mozilla.org/en-US/firefox/addon/9808

[Richard Musil (richard-musil)]

komputes: If you check the link you posted, you will notice that someone is reporting problem with race conditions on add-on parallel startup. This is understandable, because add-on should not be able enforce synchronization on the engine.
Since the request can come from either user (e.g. when opening URL) or from engine (when checking for updates for either the browser or add-on) or from add-on, it cannot be solved on add-on level.

In fact, there are two bugs as I see it:

1) Dialog for proxy authentication should not be displayed if the data are already remembered by the system (i.e. instead of displaying "pre-filed" dialog which user must confirm, the connection should be directly established). This issue seems minor, but after a while, becomes quite annoying.

2) Any request for the password which is stored should block on master password dialog first (if the master password is set) and master password dialog must be only one (i.e. appear only once). This one is not trivial. For example take the situation when the password for the proxy is not stored. It is clear that opening auth. dialog for each connection is not desirable since the password will be the same for each one and only one dialog should be used (as long as there is only one proxy configurable in the settings).

[Steve-england (steve-england)]

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

[longsonr (longsonr)]

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

[Matti-mversen (matti-mversen)]

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

[Huston (huston)]

I wonder if bug 453326 might be a duplicate of this as well, they seem to describe the same problem.

Either way, the priority of this should be moved from "normal" to "major" or even "damned showstopper". I dread having to open Firefox anymore because of the number of password dialog boxes I'm inundated with when I used to just see a single one.

[Honzab-moz (honzab-moz)]

(In reply to comment #62)
> I wonder if bug 453326 might be a duplicate of this as well, they seem to
> describe the same problem.
>

It looks like.

> Either way, the priority of this should be moved from "normal" to "major" or
> even "damned showstopper". I dread having to open Firefox anymore because of
> the number of password dialog boxes I'm inundated with when I used to just see
> a single one.

I'm stuck on remaining reviews for bug 475053 to move forward with this. It's really a pity that fix won't get to 1.9.1.

[Beltzner (beltzner)]

Honza: I'm trying to ensure we get reviews for that bug presently. How much more work is the patch here? And is this really blocked on all of the bugs listed above (bug 230190, bug 348997, bug 475053)?

[Fabián Rodríguez (magicfab)]

As a side note, I have stopped using the master password feature in Firefox completely, now that encrypted home directory is so easily accomplished. This, combined with full disk encryption, is enough for me. It also means I accept the risk of exposing my passwords if someone gets past those two layers of encryption (for example if I misplaced a non-encrypted backup, etc.).

[David (wizzardx)]

Yes, same here. These days I keep sensitive data under encfs-encrypted
sub-directories of my home dir.

2009/4/16 Fabián Rodríguez <email address hidden>:
> As a side note, I have stopped using the master password feature in
> Firefox completely, now that encrypted home directory is so easily
> accomplished. This, combined with full disk encryption, is enough for
> me. It also means I accept the risk of exposing my passwords if someone
> gets past those two layers of encryption (for example if I misplaced a
> non-encrypted backup, etc.).
>
> --
> Password asked separately for each tab that requires it
> https://bugs.launchpad.net/bugs/195698
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Mozilla Firefox Browser: Confirmed
> Status in “firefox” source package in Ubuntu: Invalid
> Status in “firefox-3.0” source package in Ubuntu: Invalid
> Status in “xulrunner-1.9” source package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: firefox
>
> Ubuntu 8.04 - Hardy (development branch)
> FIrefox 3 Beta 3
> I am connected through a proxy that needs authentication and I have multiple tabs opened.
> When main Firefox window is closed (selecting "Save and Quit" later) and I open Firefox again, multiple windows appear (one for each tab) asking for me user and proxy password. There should appear only ONE window.
>

[Gerry (gerry-spm+lnchpad)]

Those two solutions aren't much good if for instance you're logged in and people start using your computer and you can't stick around to watch everything they do. With a master password on the manager you can feel free to allow then to look up clips on Youtube and not worry about them jotting down all your passwords while you're out of the room.

[David (wizzardx)]

On the other hand, other people can (if you're not attending the PC,
and have the master password already entered), also log into your
webmail, internet banking, ebay account, etc, and start doing
nefarious things there too, even if they can't immediately see your
password in a text file somewhere.

It's basically a matter of how much you trust other people who you
leave at your PC.

If you're paranoid about such things it's better to quickly create a
new system account, lock your current window manager login, and then
login to the new window manager as the new user (and make sure that
your home directory permissions are secure).

On Sun, Apr 19, 2009 at 1:13 AM, Gerry <email address hidden> wrote:
> Those two solutions aren't much good if for instance you're logged in
> and people start using your computer and you can't stick around to watch
> everything they do. With a master password on the manager you can feel
> free to allow then to look up clips on Youtube and not worry about them
> jotting down all your passwords while you're out of the room.
>
> --
> Password asked separately for each tab that requires it
> https://bugs.launchpad.net/bugs/195698
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Mozilla Firefox Browser: Confirmed
> Status in “firefox” source package in Ubuntu: Invalid
> Status in “firefox-3.0” source package in Ubuntu: Invalid
> Status in “xulrunner-1.9” source package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: firefox
>
> Ubuntu 8.04 - Hardy (development branch)
> FIrefox 3 Beta 3
> I am connected through a proxy that needs authentication and I have multiple tabs opened.
> When main Firefox window is closed (selecting "Save and Quit" later) and I open Firefox again, multiple windows appear (one for each tab) asking for me user and proxy password. There should appear only ONE window.
>

[Gerry (gerry-spm+lnchpad)]

I agree with you that if you've entered the master password already, the
it is an issue unless you restart the browser. It would be great if there was
a button or keycombo I could press to relock the password manager, but
your method doesn't provide for that either so I was simply saying that
it offers better protection.

> It's basically a matter of how much you trust other people who you
leave at your PC.

> If you're paranoid about such things it's better to quickly create a
new system account, lock your current window manager login, and then
login to the new window manager as the new user (and make sure that
your home directory permissions are secure).

Well if you want to remain secure then you can't really trust them at all.
Even if you trust them, you may have others who rely on you not to trust
other people with that data.

It's not necessary about paranoia, it could just be about security. The
problem with your solution is that it will make your fiends, girlfriend,
associates etc. think badly of you. You can't let people know that you are
going out of your way because you don't trust them, because that offends
people which will then impact on you. :) Restarting firefox is much easier to
disguise. But as I said, the ideal solution would be to be able to hit a button
or key combo to relock the manager.

However my point was that disk encryption won't protect you in this
situation at all. I'm assuming if you unmounted the encrypted folder then
things would just stop working?

[htamas (htamas2)]

You can relock the password manager:
Edit > Preferences > Advanced > Encryption > Security Devices > Software Security Device > Log Out

[Gerry (gerry-spm+lnchpad)]

Wow that's fantastic htamas! That option is very well hidden, very nice find. :) If only there was a shortcut for it.

[htamas (htamas2)]

This option shouldn't be considered hidden, because it's accessible from the menu system :).
There are lots of others which require some knowledge of mozilla internals.
I'll give some shortcuts below as examples:

1. The "Security Devices" dialog has an url (you can open it directly or add it to your bookmarks):
chrome://pippki/content/device_manager.xul

2. You can also use some javascript (open Tools > Error Console [Ctrl+Shift+J], paste the following line of text in the Code box and press Enter or click Evaluate):
Components.classes["@mozilla.org/security/pk11tokendb;1"].getService(Components.interfaces.nsIPK11TokenDB).findTokenByName("").logoutSimple();
(Note: There will be no feedback, so you should check that you're really logged out. You can do so with almost the same command, substituting isLoggedIn for logoutSimple.)

3. If you plan to use it frequently, you may create a firefox extension that adds it to the tools menu and gives it a shortcut key.
It's a bit off-topic and about 30 lines of code, so I've put it here: http://pastebin.com/f7cd21c99 (should I create an attachment?)

+1. In some circumstances you may use Tools > Clear Private Data [Ctrl+Shift+Del], ticking only "Authenticated Sessions". This does a bit more to logging out from the software security device, but makes sense to use when letting others to your computer.

[Gerry (gerry-spm+lnchpad)]

Firstly you are right, I should have said "the option is quite deep in the menu system and thus may be easy for the typical user to overlook". However more importantly, I didn't not realise that clearing Authenticated Sessions also logged you out of the password manager, I had assumed it was just clearing HTTP/S Authentication sessions. This then is a more appropriate option as you have said. I have changed the defaults of what is cleared by going to
Preferences -> Privacy > Private Data > Settings
and unchecking everything except "Authenticated Sessions" and then I unchecked the option
Preferences -> Privacy > Private Data > Settings > Ask me before clearing private data

Now the [Ctrl+Shift+Del] option clears exactly what I want cleared. Thank you!

Thank you so much for all the information. I was so excited when I got to the part about the extension that I went ahead and created it before reading on. I have attached the generated extension from your instructions (with the author changed to yourself though :) ). I'm sure it will be useful to somebody searching for that exact thing.

So now we have a good and clear use case for continued use of the password manager combined with the option for clearing authenticated sessions regardless of weather you are using an encrypted home folder. So you're post actually put us back on topic. :)

[Randy-steer (randy-steer)]

This is a real annoyance, and bug 453326 only reports the tip of the iceberg for pages requiring login -- you get the same repeated requests for master password if you have multiple login-dependent tabs to open on restart, just as the other users have reported for multiple proxy-dependent tabs. I think I've noticed this ever since 3.0.

I routinely have to type in my master password anywhere from 4 to 8 times to open my saved tabs every morning.

There should be a way for the first triggering of a request for master password to set a flag in the program so that any other triggerings simply wait. That would mean just one master password even if the tabs being loaded included a mix of login pages and proxy pages. Looks like bug 475053 is on the path to fixing this, but make sure that the fix is applied to pages with login fields as well as proxy-dependent pages.

[Andrewa (andrewa)]

Here's another piece of info about this problem.

While I experience the master password issue at home as described above, there's another (related?) issue with the proxy login dialog.

At University when I start Firefox, I am prompted multiple times for the proxy login details because:

* Plugin Update wants to check for updates
* Multiple tabs are loading

[Ulrich-windl (ulrich-windl)]

Hello everybody, I'd like to add a "me to" for Windows/XP and Firefox 3.0.6 to 3.0.8 (at least). Unfortunately this bug as an unfurtunate "complaints and suggestions" to "solutions" ratio, partly because some unlelated or new issues were mixed in. I think that commnet #1 describes it most exactly, maybe with the addition that you need to have a non-trivial master passord and the FIPS option enabled. Important IMHO are comment #66 and comment #86.
When I hit that bug for the first time, I thought, I had mistyped my master password, and that's because all the dialogs that prompt for a master password are exactly on top on one another. That means if you entered your password correctly into the topmost dialog, that will vanish, making the next-to-top one appear. However for the user it just looks as if the password field was emptied and the user should retype the password (as if that were wrong).
Experimenting I also found out (sorry if someone reported that already) that it's sufficient to enter the master password to any of the dialogs and press "Cancel" for all the others. OK, for far for the effects...
The most primitive solution (pre-step for any solution) would be (IMHO) to place the individual dialogs not exactly on top of each other, and not to give different instances of the same dialog the same window title. That would make the problem at least more obvious to users.

[ericjung (eric-jung)]

(In reply to comment #194)

> I now only get lots of proxy auth dialogs

FoxyProxy Plus solves this issue. Screenshot:
http://foxyproxy.mozdev.org/fpplus/images/screenshots/current/auth.png
More info:
http://foxyproxy.mozdev.org/fpplus

[Profiart (profiart)]

I Dont't know where is the Problem anymore. I use the Addon StartupMaster and it works for me. I open the Browser with 80-100 Tabs open and there is ony ONE Dialog for the MasterPassword on Start - nothing more. Don't know, why the Mozilla Team it don't implement in the Core-Application.

StartupMaster is the Solution for the Problem

[Bugzilla-98020084357862 (bugzilla-98020084357862)]

(In reply to comment #238)
> (In reply to comment #194)
> FoxyProxy Plus solves this issue.
Paying 45 USD (3 computers) each year to solve a bug? Considering the lifetime of this bug may very well mean another 5 years, which would result in over 200 USD. So no, that's not an option.
I'd be willing to spend 45 USD once to finally get someone to fix this bug, but I'm not willing to pay for a workaround.

[a.h() (a.h)]

I know the add-on fixes this problem, but shouldn't firefox be modified, so that when a password manager call is made, as will be made by every tab on startup if a password is required and you haven't authenticated yet, firefox first checks whether there is already a password dialog open, and if this is the case, it doesn't open another one. This means that the first tab to want a password will cause the dialog to appear, the other calls will simply be ignored, and then once the password is entered everything works as normal. (I.e. set firefox up so that only one password dialog can ever appear.)

[billythegates (mfittko)]

That would be – imo and as far as I can judge this – a really simple
but smart approach to get rid of this ridiculous problem which forces
me to disable the master password feature completely. But the question
is why noone came up with such an idea before?!

Best,
Manuel Fittko

Am 13.05.2009 um 14:14 schrieb and.hunt:

> I know the add-on fixes this problem, but shouldn't firefox be
> modified,
> so that when a password manager call is made, as will be made by every
> tab on startup if a password is required and you haven't authenticated
> yet, firefox first checks whether there is already a password dialog
> open, and if this is the case, it doesn't open another one. This means
> that the first tab to want a password will cause the dialog to appear,
> the other calls will simply be ignored, and then once the password is
> entered everything works as normal. (I.e. set firefox up so that only
> one password dialog can ever appear.)
>
> --
> Password asked separately for each tab that requires it
> https://bugs.launchpad.net/bugs/195698
> You received this bug notification because you are a direct subscriber
> of the bug.

[Savvas Radevic (medigeek)]

You could just use the secure login addon: https://addons.mozilla.org/en-US/firefox/addon/4429
If you middle-click (the scroll button), it logs you out automagically. ;)

By the way, this seems to be related to this upstream bug as well:
https://bugzilla.mozilla.org/show_bug.cgi?id=230190
..which is there since 2004, I wonder why is it so hard to make it pop up only one password, perhaps some security issues in the way?

[Kevin Brosnan (kbrosnan)]

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

[Morpheus (morpheus)]

I can confirm that this problem is not limited to "session restore" but it also occurs if you have multiple homepages that require HTTP authentication.

[Aarondoom (aarondoom)]

This also happens when cross-domain sub content is loaded, let's say 1,000 pictures of movies of password protected content need loaded, Firefox attempts to load 1,000 password requests... and hangs in the process.

Why would more than one password box per domain ever be required?

Why not just ask once per domain and not have Firefox hang and require killing?

Or for that matter, why would you have more than one application dialog up at a time waiting for a response?

[Dpeelen (dpeelen)]

(In reply to comment #243)
> Why would more than one password box per domain ever be required?
>
> Why not just ask once per domain and not have Firefox hang and require killing?
>
> Or for that matter, why would you have more than one application dialog up at a
> time waiting for a response?

Because this is a bug, silly.

[Zeniko (zeniko)]

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

[gruewo (cobexer)]

I can confirm this behavior of Firefox since I use a master password - on all platforms I use (Win XP SP0,1,2,3; openSuSE 11.0,11.0,11.2(Factory)) with Firefox 3.x and 3.5 (all versions i ever used of it).

This bug is absolutely annoying and sometimes stops firefox from working (eg 60 tabs open wich all ask for the master password (proxy auth) -> typing into a password field becomes impossible and closing them is also sometimes impossible(FF locks down?!)

implementing the master password prompt seems to be a good solution for this because a user can only have 1 master password so no need to ask multiple times.

As I see it this should be fixed to all applicable versions and distributed as recommended update.

best regards
cobexer

[Polidobj (polidobj)]

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

[Sergmarchenko (sergmarchenko)]

Please fix "too many password prompts for the same(!!!!) http proxy" bug, at least. It is very frustrating and occurs every time I launch FF with saved tabs.

[Carleeto (carleeto)]

Confirming this bug on Firefox 3.5b99 :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b99) Gecko/
20090605 Firefox/3.5b99 GTB5 (.NET CLR 3.5.30729)

I have to admit it is enough to make you want to not use a master
password. A feature that promises more peace of mind should not make
you realize you were better off without it.
Could this please be fixed before the 3.5 release? Given all the new
privacy features in 3.5, it would really feel incomplete if a feature
like this was left in this state.

[oneguycoding (steeve-oneguycoding)]

Carl et al., I would recommend that you install the StartupMaster firefox addon, it solves the problem by prompting for the master password very early in the startup sequence. Works for me.

[Patoche-smart+mozilla (patoche-smart+mozilla)]

(In reply to comment #66)
> * Plugin Update wants to check for updates

Yes, I have the feeling this part has gotten worse with one of the last 3.5 beta.

I am nominating "wanted" flags for this very long lasting bug in an attempt to call for attention. I hope not to bother too much with this.

Patrick

[Bugzilla-98020084357862 (bugzilla-98020084357862)]

@steeve
StartupMaster does not solve it, it only makes it slightly less annoying. I am still facing about 20 prompts for the proxy password which partly block eachother, forcing me to click around 50 times until they are gone, as Firefox seems to ignore a lot of the clicks.

[Volkmarkostka (volkmarkostka)]

A workaround for the proxy issue is found in bug 339804 comment 87.

[ericjung (eric-jung)]

(In reply to comment #251)
> A workaround for the proxy issue is found in bug 339804 comment 87.

It is also in this bug... comment 238

[Matti-mversen (matti-mversen)]

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

[Maddes (maddes)]

This also affects Thunderbird (here 2.0.0.21):
If you set a short time for mail checking (e.g. 3 minutes) and get distracted by a phone call for 15 minutes, then you have to enter the master password several times.
Very annoying. Voted.

[Dolske (dolske)]

Multiple master password prompts can be triggered in a variety of ways. Bug 475053 will fix many of them, by serializing HTTP auth and proxy auth prompts. The main remaining cause will be from opening multiple tabs with logins available (perhaps at startup), each of which triggers a master password prompt.

Login manager may need to serialize the filling of forms in a similar way, so that multiple master password prompts are not invoked. Alternately, we may (instead? also?) want to look at involving PSM in the fix, so that opening 1 tab with form auth and 1 tab with HTTP auth don't each invoke a master password prompt.

[I'm filing a new bug on this, since the tangle of existing bugs is an unhelpful mess.]

[Dolske (dolske)]

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

[Aaron Peromsik (aperomsik)]

I have been having this problem for a while and finally got around to finding the bug report. I normally have 20-30 tabs open, mostly on the same half-dozen internal company sites. Restarting firefox becomes a chore.

The fix I would like to see would go like this: if a tab other than the active tab needs a password, it would not display a prompt until that tab is activated. If that site has already been authenticated (in another tab) by the time the tab is activated, no prompt would be presented when activating the tab.

For bonus points, as soon as I authenticate a site in one tab, all other tabs for the same site could resume loading in the background.

[Matti-mversen (matti-mversen)]

isn't this a dupe of bug 356097 ?

[Dolske (dolske)]

No. Bug 356097 is about proxy auth, and will be fixed by bug 475053.

[Gavin Taylor (gavtaylor)]

I can confirm this issue is still present in 3.5rc2.

during the course of my day I can have numerous tabs open and if firefox crashes or I restart it after an add-on installation etc the process of typing my master password over and over again is more than a chore.

I now resort to clicking cancel on each notification and then just reloading the tabs manually, this means i only have to type my master password once.

would be nice if the priority of this bug was increased as this bug report was submitted on 2006-08-17 05:53

[Erik-hensema-net (erik-hensema-net)]

Could this bug please be made blocking 3.5? It's really a shame large new features are added to the browser, while extremely annoying bugs like this one aren't fixed.

Please do realize this bug enables a very simple DoS: just link 50 images from an external site which requires basic auth, and most users will kill their browser in despair. Clicking 'cancel' 50 times *IN THE RIGHT ORDER* is no fun at all.

So, *please* don't release ff 3.5 without this fix. It's essential.

[Beltzner (beltzner)]

Everyone: we know what the problem is (read previous comments), we know that a fix is needed (again, read previous comments), we know that the problem still exists (thus the bug is open), it has been marked as not-blocking (see the blocking status flag).

We acknowledge it sucks. Right now the fix is riskier than the problem, in our opinion, so it will have to wait until a future version, either a stability release or the next version of Firefox. Sorry for the inconvenience to those who use a lot of basic http-auth and/or the master password, truly, we do understand your pain here.

[Brian J. Murrell (brian-interlinx)]

(In reply to comment #257)
>
> We acknowledge it sucks.

And has sucked for a long (long, long, long) time! This bug has been open for almost three years now.

> Right now the fix is riskier than the problem, in our
> opinion, so it will have to wait until a future version, either a stability
> release or the next version of Firefox.

But this has been the situation for 3 years now. Why are we to believe that another 3 years won't go by with still no fix? In the three years that have gone by, how many releases have been made with how many new features added and this bug not fixed?

> Sorry for the inconvenience to those
> who use a lot of basic http-auth and/or the master password, truly, we do
> understand your pain here

Then please give it a priority that gets it better treatment than allowing 3 years to pass without it being fixed. Please.

Please.

And thanks, in advance.

[Jwalden+bmo (jwalden+bmo)]

There are many bugs which have been open three years and haven't been fixed. We don't fix bugs solely on the basis of how long they've been opened. We consider the severity of the bad behavior, likelihood the typical user will hit it, the frequency at which the bad behavior is hit, interaction with other potential bugfixes or existing bugs, and at certain periods during release cycles (as now) the complexity of the fix and the estimated time to stabilize the functionality and address regressions. (I may have forgotten one or two criteria, but these hit most of the high points.) Taking everything in total, it's been deferred so far, but as there's been recent (taking into account crunch time for the 3.5 release) work on patches here, I think you have good reason to hope this bug may be fixed in the near future. That said, there are no promises: if you want promises regarding a bug, pay someone to fix it for you (and if you want that fix in future releases and not just your own custom build, pay someone to fix it *right*).

In any case, your complaints add nothing substantial to this bug and make it more difficult to approach this bug (did you really read all 257 comments before yours?). Indeed, after 259 comments it's difficult to say *anything* other than patches or review comments are substantial. Finally, consider also that every useless comment spams 140-odd people.

In summary: complaints about a bug and requests for status updates have no place in bug comments because they make bugs harder to read while simultaneously spamming large numbers of people.

[Bmo-2 (bmo-2)]

it's also important to note that a reasonable workaround was posted in comment 196 six months ago.

quit whining and install this, already:
https://addons.mozilla.org/en-US/firefox/addon/9808

[Christian Holtje (docwhat)]

Marc Bejarano:

Thank you for your suggestion. It helpfully mitigates part of the problem and I do indeed use it.

However, this only solves the "master password" part of the problem.

In my case, I have about 5-20 windows that all require HTTP authentication. When I resume a session, each window asks for my HTTP authentication username and password.

Ciao!

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing)]

Ubuntu Bug:
https://bugs.launchpad.net/bugs/398128

User was seeing this in 3.0.11 and I'm seeing this in 3.5.

[Honzab-moz (honzab-moz)]

Fixed today on m-c (1.9.1a1) in bug 475053.

[Honzab-moz (honzab-moz)]

(In reply to comment #264)
> Fixed today on m-c (1.9.1a1) in bug 475053.

Err, on 1.9._2_a1!

[Honzab-moz (honzab-moz)]

(In reply to comment #70)
> Fixed today on m-c (1.9.1a1) in bug 475053.

Err, on 1.9._2_a1!

[Micah Gersten (micahg)]

Only Security Fixes for xulrunner-1.9 at this point.

[Savvas Radevic (medigeek)]

Oops, sorry, I thought it was for firefox-3.5 when I nominated it. Thanks for signing it up for firefox-3.5 :)

[patcito (patcito)]

Nice, will this be backported to firefox 3.5?

[Digulla-hepe (digulla-hepe)]

I had a long discussion about this with Boris. They are considering it but maybe it won't be possible to implement until October (when 3.6 comes out which contains the fix).

[Randy-steer (randy-steer)]

THIS is what I've been voting for in multiple other bugs (from 3.0 to 3.5). I don't understand why it's not all considered one bug. A tab/process/thread opens a URL and -- for whatever reason -- a login is required and a call is made to the master password dialog. For future maintenance alone, I would think that all of those circumstances would be using the same call and subroutines for master password. Can't the call for master password check, and if necessary set, a flag, and then put each process/thread in a queue until the MP is entered?

[Patoche-smart+mozilla (patoche-smart+mozilla)]

(In reply to comment #73)
> I had a long discussion about this with Boris. They are considering it but
> maybe it won't be possible to implement until October (when 3.6 comes out which
> contains the fix).

Taking into account that I reported this bug back in October 2006, I am just happy this has been tackled and will be implemented in a few months.

This has clearly been the most annoying bug in FF for me.

Thank you!

Patrick

[Andrewa (andrewa)]

Note there is an add-on you can use to work around this problem in the mean time by asking once for the master password at startup: https://addons.mozilla.org/en-US/firefox/addon/9808

[Georgi Georgiev (chutz)]

(In reply to comment #75)
> Note there is an add-on you can use to work around this problem in the mean
> time by asking once for the master password at startup:
> https://addons.mozilla.org/en-US/firefox/addon/9808

Let it be known that even though the add-on makes sure that the proxy password prompts have my name and password filled in I still have to click OK (or press enter) on multiple dialog boxes. Restoring a saved session with many tabs is still annoying.

[patcito (patcito)]

Try this extension it will auto submit
https://addons.mozilla.org/en-US/firefox/addon/4949

[Tomlevels (tomlevels)]

Hm, this still does not fix the bug that multiple prompts are shown from extensions which need a password. Is there a seperate bug for this problem?

[Georgi Georgiev (chutz)]

(In reply to comment #77)
> Try this extension it will auto submit
> https://addons.mozilla.org/en-US/firefox/addon/4949

Patrick, .... (looking for the right words and not finding any)... thank you.

[Jo-hermans (jo-hermans)]

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

[Munka-maniac (munka-maniac)]

(In reply to comment #77)
> Try this extension it will auto submit
> https://addons.mozilla.org/en-US/firefox/addon/4949

it's not a bit solving it, still asks for as many master password as tabs it wants to open (or even more)

[Jo-hermans (jo-hermans)]

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

[Hskupin (hskupin)]

Verified fixed with builds on OS X and Windows like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090803 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090803044626

[Jonny (dioni21)]

Bug 369963 is marked as solved, but indeed is a duplicated of this, and therefore, unsolved...

It is a very old and annoying bug for those who keep many open tabs between browser restarts.

[Brendan-webafrica (brendan-webafrica)]

Is bug 499233 a dupe?

P.S. if anyone can verify that this is *not* fixed, provide a screenshot. ;)

[Morac99-firefox (morac99-firefox)]

It's not a dupe, read bug 499233 comment #3

[Rnicoletto (rnicoletto)]

(In reply to comment #6)
> Bug 369963 is marked as solved, but indeed is a duplicated of this, and
> therefore, unsolved...
>
> It is a very old and annoying bug for those who keep many open tabs between
> browser restarts.

bug 475053 has been resolved and landed on trunk. If you're experiencing this bug try reproducing with a clean profile on latest trunk version (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/).

[Jasonb-dante (jasonb-dante)]

Bug 475053 is not the same thing and it did not fix this. (Already tested with nightlies after it was checked in.)

[Askmike2009 (askmike2009)]

Same problem (I think it was not the case in Firefox 2): I have several tabs opening at startup with identification sessions for which my credentials are saved. It triggers a corresponding number of Master Password requests instead of one request for all.

Reproducible: Always

Steps to Reproduce:
1. Have as startup page with two (or more) tabs with identification sessions (for instance your email account and another account)
2. Have the Master Password remember your credentials for the said tabs
3. Restart Firefox

Actual Results:
You will have two (or more) prompts for Master Password; filling in the first prompt will not make the other prompts disappear.

Expected Results:
Have one prompt for all.

Uneducated guess:
Recognition of a website with credentials saved in Master Password should not trigger immediate prompt for Master Password but a CHECK for existence of untreated (i.e. not filled in correctly and not canceled) Master Password prompt.

[hidenosuke (hidenosuke)]

(In reply to comment #80)
> (In reply to comment #77)
> > Try this extension it will auto submit
> > https://addons.mozilla.org/en-US/firefox/addon/4949
>
> it's not a bit solving it, still asks for as many master password as tabs it
> wants to open (or even more)

Me too with trunk/Linux.
It's not fixed.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090807 Minefield/3.6a1pre

[Hskupin (hskupin)]

(In reply to comment #82)
> > it's not a bit solving it, still asks for as many master password as tabs it
> > wants to open (or even more)
>
> Me too with trunk/Linux.
> It's not fixed.

And you are sure those prompts are for HTTP/Proxy authentications? Or are those normal login fields on the web page itself? If it is the latter please stop commenting on this bug.

[hidenosuke (hidenosuke)]

(In reply to comment #83)
> (In reply to comment #82)
> > > it's not a bit solving it, still asks for as many master password as tabs it
> > > wants to open (or even more)
> >
> > Me too with trunk/Linux.
> > It's not fixed.
>
> And you are sure those prompts are for HTTP/Proxy authentications? Or are those
> normal login fields on the web page itself? If it is the latter please stop
> commenting on this bug.

They were normal login fields.
I am sorry, I misunderstood it.

[Phoenix (phoenix-dominion)]

Dialog Boxes are evil - why can't the request be done like the one for invalid certificates?

In older version of FF a dialogbox jumped when a certificate was invalid, meanwhile this is done within the tab - same could be done for basic auth requests - so a auth request wouldn't block the browser, nor would it be irritating in the event of multiple simultanous requests.

[Micah Gersten (micahg)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A cert dialog happens before the tab content loads. An auth box would
seem like a form login if it was before content loads. Afterwards,
you're removing the content to display a login. The behavior is
standard in all browsers AFAIK.

Phoenix wrote:
> Dialog Boxes are evil - why can't the request be done like the one
> for invalid certificates?
>
> In older version of FF a dialogbox jumped when a certificate was
> invalid, meanwhile this is done within the tab - same could be done
> for basic auth requests - so a auth request wouldn't block the
> browser, nor would it be irritating in the event of multiple
> simultanous requests.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkp/CuoACgkQTniv4aqX/VnZlACfXih+IhD2/DlLqEg6rb+m1r3U
D3oAnRjsJCL9ASV4RnkzyJR0qEW75bt6
=pLyn
-----END PGP SIGNATURE-----

[Phoenix (phoenix-dominion)]

Yes, the login would appear like a form login - just like the cert thing behaves like an AJAX form. Multiple Windows and Pop-Ups are bad Browser Design - it was fine in the days, where users just served one page at a time, but tabbed browsing was the start of recognizing that users are surfing multiple pages at a time, where dialog boxes in pop-up form of any kind are bad usability. As of know, there are about 2 browsers that share the most userbase, where one browser is not really known for being innovative not standard compliance, so I have no troubles is FF would be first cleaning up this issue.

[Micah Gersten (micahg)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please file a new bug for this and I'll look into upstreaming it.

Phoenix wrote:
> Yes, the login would appear like a form login - just like the cert thing
> behaves like an AJAX form. Multiple Windows and Pop-Ups are bad Browser
> Design - it was fine in the days, where users just served one page at a
> time, but tabbed browsing was the start of recognizing that users are
> surfing multiple pages at a time, where dialog boxes in pop-up form of
> any kind are bad usability. As of know, there are about 2 browsers that
> share the most userbase, where one browser is not really known for being
> innovative not standard compliance, so I have no troubles is FF would be
> first cleaning up this issue.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkp/JcEACgkQTniv4aqX/VnBfQCfVFl652TPk4FeJ5DwiLVGTN7A
lcEAn2Q/dnLJ+R/5xl846OmpBShP8CGv
=JU9D
-----END PGP SIGNATURE-----

[Bugzilla (bugzilla)]

I can confirm this. It annoys me every day when I start up Firefox. It's been the case for all of Firefox 3 and Firefox 2 as well, for as long as I can remember.

Entering the master password correctly on each individual prompt causes the login credentials for the respective tab (whichever it is) to fill in, and for those you cancel, they are not, so it's obviously every process for itself.

I don't know how it's implemented at the moment, but maybe it should be set up in a callback format, a little like AJAX requests. Password manager remembers whether a prompt is open, and while there's no response from the user, it queues the requests and finally calls the callback functions for each tab that was asking for credentials.

[Nickolay Ponomarev (asqueella)]

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

[Paul-oshannessy (paul-oshannessy)]

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

[Dolske (dolske)]

Created an attachment (id=400653)
Patch v.1 (WIP)

Somewhat rough work-in-progress. Still need to handle a few edge cases, clean things up, and add tests. But the basic concept works with this.

[Kai Engert (kaie)]

(From update of attachment 318923)
removing obsolete review request in fixed bug

[Dolske (dolske)]

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

[Dolske (dolske)]

Created an attachment (id=403604)
Patch v.2 (WIP)

Cleaned up, still a few todos and needs tests, but I'll toss it to zpao for a prereview.

[Paul-oshannessy (paul-oshannessy)]

(From update of attachment 403604)
>+ // XXX Can we detect if this document has died in the time since
>+ // we deferted it?

My question too. You can write a test for it :) (or at least make sure we have a litmus test)

>+ // XXX do we need be able to defer this too?

Presumably yes? You know the code better, but if we haven't decrypted anything for the form yet, I would think this would have to be deferred.

All-in-all it looks good. You know the parts you need to finish. My only concern (and one you say you know the answer to) is how this affects 3rd party consumers. If I'm understanding this right, it shouldn't actually affect them at all since they mostly aren't trying to fill forms.

[Ria-klaassen (ria-klaassen)]

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

[Ria-klaassen (ria-klaassen)]

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

[John-p-baker (john-p-baker)]

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

[longsonr (longsonr)]

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

[Paul-oshannessy (paul-oshannessy)]

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

[Jo-hermans (jo-hermans)]

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

[Tomlevels (tomlevels)]

I used to have an extension which solved this problem, but since a few days it does not work anymore. Any progress on the fix?

[Bugzilla-henrik (bugzilla-henrik)]

I still get multiple master password prompts upon startup with multiple tabs in Namaroka 3.6b2pre (mozilla-1.9.2/rev/7347a2572f1d) running on MacOSX 10.6.

(Brendan Hide: I cannot provide a screenshot since the MacOSX version displays the master password dialogues sequencially.)

[Bugzilla-henrik (bugzilla-henrik)]

I also get multiple master password prompts upon startup with multiple tabs. I'm using Namaroka 3.6b2pre (mozilla-1.9.2/rev/7347a2572f1d) running on MacOSX 10.6.

The StartupMaster add-on (https://addons.mozilla.org/en-US/firefox/addon/9808) can be used as a workaround, but it's definately not perfect.

[Mitchs-bugzilla (mitchs-bugzilla)]

This hasta make it in to 3.6, this bug is old.

Many have suggested putting the master password prompt first, before any windows open, this (would) have solved both bugs. Is this what the patch does?

[Honzab-moz (honzab-moz)]

Works perfectly! The memory problem seems to be a bug in Apoint.exe but I'll keep an eye on it. Thanks for fixing this.

[Honzab-moz (honzab-moz)]

(In reply to comment #21)
> Works perfectly! The memory problem seems to be a bug in Apoint.exe but I'll
> keep an eye on it. Thanks for fixing this.

Sorry, wrong bug.

[Paul-oshannessy (paul-oshannessy)]

(In reply to comment #20)
> This hasta make it in to 3.6, this bug is old.

Unless our plans drastically change, this won't happen - plan is to freeze for RC next week, and this (and the changes it depends on) haven't even made it onto trunk yet.

> Many have suggested putting the master password prompt first, before any
> windows open, this (would) have solved both bugs. Is this what the patch does?

No, this patch keeps track of whether or not we're showing the master password UI, if you enter it once, the other requests for it get notified so they don't also popup the dialog.

[Gavin Taylor (gavtaylor)]

this bug was resolved in Fx3.6b1 but seems to have returned in Fx3.6b2,
I have just updated to 3.6b3 and the bug is also present in this build

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b3) Gecko/20091115 Firefox/3.6b3 (.NET CLR 3.5.30729)

[Tomlevels (tomlevels)]

Is there a seperate bug for multiple password prompts when using extensions which use a password from the password manager? I use Weave and Gmail notifier and always get two password prompts.

[Bugs-mattclare (bugs-mattclare)]

It's not just extensions. If you set a master password and have n tabs that need a password open when you first launch Firefox you'll get n password prompts.

[Ria-klaassen (ria-klaassen)]

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

[Simon-marchese (simon-marchese)]

(In reply to comment #260)
> it's also important to note that a reasonable workaround was posted in comment
> 196 six months ago.
>
> quit whining and install this, already:
> https://addons.mozilla.org/en-US/firefox/addon/9808

This add-on is a workaround and not a fix. We need a fix to stop users drifting away from Firefox in irritation. Note yourself that this bug was not always in the code.

[Srcmax (srcmax)]

Any progress on the fix?

The bug is always present in 3.6b4 and it's very irritating ... I hope it will be fix in 3.6 final.

[sudarsha (sudarsha)]

* I am using firefox 3.5.5
* I have to use an authenticated http proxy at work.
* I have a master password set to encrypt my stored passwords including the proxy authentication password.
* I have some common addons like adblock plus and noscript.

Sometimes restore firefox sessions with multiple tabs open and this bug is driving me to the verge of insanity. It seems like this has been a problem with firefox forever. I am finally writing here wondering when will this be truly fixed? I can not belive this is not driving others up walls like it does to me and I can not understand why it would be so hard to just ask for master password once when starting the browser.

[Kevin Brosnan (kbrosnan)]

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

[Gavin Sharp (gavin-sharp)]

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

[Mprindle (mprindle)]

FF 3.5.5, Windows XP SP3

I can also confirm that this bug still exists. I have two addins that require passwords and I get two password prompts when starting FF.

[Dpeelen (dpeelen)]

THIS IS ONLY FIXED IN 3.6 AND ABOVE. Please stop spamming this bug unless you can still reproduce it in 3.6 or above.

[Tomlevels (tomlevels)]

This bug is NOT FIXED in 3.6 and above. FF 3.7 (latest nightly build), Windows 7:
I have two addons that require passwords and I get two password prompts when starting FF.

[Srcmax (srcmax)]

I confirm. This is NOT FIXED in FF 3.6b4, Windows XP

[Aaron Peromsik (aperomsik)]

When I launch FF 3.5.5, I get more than a dozen password prompts, all at once, many of them duplicated. When I launch FF 3.6b4, I get fewer than half a dozen prompts, seemingly consecutive instead of simultaneous, and only one per site. (I have multiple tabs open per site.)

So I call it fixed. Those who say it is not fixed, are you sure the issue you are seeing is the same one described here (in the description / comment 0)?

[Ulrich-windl (ulrich-windl)]

On comment #283:
> So I call it fixed. Those who say it is not fixed, are you sure the issue you
> are seeing is the same one described here (in the description / comment 0)?

So all the duplicates that were directed to this bug should be fixed? IMHO A master password should be asked for exactly _once_, no matter how many tabs are busy at startup.

[Srcmax (srcmax)]

(In reply to comment #284)
> So all the duplicates that were directed to this bug should be fixed? IMHO A
> master password should be asked for exactly _once_, no matter how many tabs are
> busy at startup.

I agree with you. The problem concerns the master password.

[oneguycoding (steeve-oneguycoding)]

The bug concerning multiple master password prompts is here: https://bugzilla.mozilla.org/show_bug.cgi?id=499233

This bug concerns multiple prompts for an authentication dialog.

[Mozbug1 (mozbug1)]

I am still getting multiple prompts for an authentication dialog with FF 3.5.5

[Honzab-moz (honzab-moz)]

(In reply to comment #281)
> This bug is NOT FIXED in 3.6 and above. FF 3.7 (latest nightly build), Windows
> 7:
> I have two addons that require passwords and I get two password prompts when
> starting FF.

@Tom Levels: What exact kind of a password prompt you mean? Dialogs that the addons invoke?

[Tomlevels (tomlevels)]

No. I have GMail notifier and Weave, which both require the password manager to provide a password. The problem is that I have to enter the master password for both extensions at startup.

[Srcmax (srcmax)]

(In reply to comment #73)
> I had a long discussion about this with Boris. They are considering it but
> maybe it won't be possible to implement until October (when 3.6 comes out which
> contains the fix).

In FF 3.6b5 this bug is not fixed. This is the most unbearable bug in Firefox.
I do not understand how it is posibble it is still not resolved after so many years.

How is it that this bug is marked as resolved?

[Srcmax (srcmax)]

(In reply to comment #39)
> Clearly this is a usability bug. It is a security risk in that if a person
> gets conditioned to entering his master password into a lot of dialog boxes a
> malicious app could throw up a similar dialog.
>
> I agree with Mike that this is core functionality that cannot be trusted to a
> plugin.
> I applaud Hubai for writing the plugin, but I don't know anything about him and
> am not about to risk my master password.

Totally agree with you. And this bug still reproduce in FF 3.6b5.
I do not understand how it is posibble it is still not resolved after so many
years.
This bug scares away many users ....

[Honzab-moz (honzab-moz)]

Maxime, can you please describe how you reproduce this bug, provide a steps to reproduce? W/o further information your comment is a bit useless and we cannot figure out what's wrong. Thanks for more info.

This bug has been marked as fixed because a test according to steps-to-reproduce from description of this bug showed the problem had really been fixed.

Just let you know that there still are bugs in this area, we fixed so far only the most annoying and common cases.

[Georges (georgeskesseler)]

I confirm, it is *fixed* but only for proxy authentication.

It is not fixed for form password logins.

There is even a race condition between the two. If proxy auth comes first, the forms don't trigger multiple prompts.
If forms come first there's a bonus master password prompt for the proxy auth.

Problem is that Bug 369963 talks about forms based passwords. That bug is marked duplicate of Bug 177175 which in turn is duplicate of THIS bug.

So in end, the form password bug is marked fixed through the bug dependencies but in reality it's *not* fixed.

So what now? Shall I open a new bug which will be immediately marked as duplicate of the wrongly fixed bugs?

On what bug should we comment if we have multiple passwords for forms based authentication?

[Patoche-smart+mozilla (patoche-smart+mozilla)]

Isn't it Bug 348997 that you're talking about?

[CobraBKeX (cobrabkex)]

Details are also explained in Bug 533086

[Nickolay Ponomarev (asqueella)]

<email address hidden>: multiple master passwords for forms in different tabs is bug 499233, but please don't add unnecessary comments to that bug.

What you can do if you care about this issue is to make sure all the cases, that lead to master password appearing several times, are already reported and are linked from some central place.

You can see the list of open bugs mentioning master password here:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=:Core,Firefox,Toolkit%20master%20password
A good place for listing other cases that can lead to extra dialogs is at:
https://wiki.mozilla.org/Firefox/Projects/Eradicate_Startup_Dialogs#Related_Bugs
(right now there's only bug 499233 on this issue).

[Nelson-bolyard (nelson-bolyard)]

In comment 92, Gunstick wrote:
> Problem is that Bug 369963 talks about forms based passwords. That bug is
> marked duplicate of Bug 177175 which in turn is duplicate of THIS bug.
> So in end, the form password bug is marked fixed through the bug
> dependencies but in reality it's *not* fixed.

I'd reopen it (unmark it as duplicate), but comments 93 and 94 suggest that
there is disagreement about which bugs are the proper ones to reopen.
If you all can reach consensus on which bugs are still unfixed, they can be
unmarked as duplicates and reopened.

[Georges (georgeskesseler)]

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.

[CobraBKeX (cobrabkex)]

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.

[Digulla-hepe (digulla-hepe)]

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.

[Digulla-hepe (digulla-hepe)]

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.

[Kairo-kairo (kairo-kairo)]

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

[Chelmite (steve-kelem)]

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!

[Dolske (dolske)]

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.

[Brendan-webafrica (brendan-webafrica)]

#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?

[Joshprogramming (joshprogramming)]

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.

[Jjfelten (jjfelten)]

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

[Jonathan Pritchard (jonathanr-pritchard+bugzilla)]

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.

[Digulla-hepe (digulla-hepe)]

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.

[Mstamat (mstamat)]

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.

[Kairo-kairo (kairo-kairo)]

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.

[Digulla-hepe (digulla-hepe)]

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?

[Faaborg (faaborg)]

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

[Hskupin (hskupin)]

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

[Ulrich-windl (ulrich-windl)]

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

[Beltzner (beltzner)]

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.

[Catlee (catlee)]

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

[Dolske (dolske)]

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.

[Etcoproc (etcoproc)]

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

[Clappingman (woova165)]

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.

[Rnicoletto (rnicoletto)]

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

[Abiedron (abiedron)]

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.

[Dolske (dolske)]

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.

[Micah Gersten (micahg)]

firefox is the source package for Firefox 3.6, so reopening this task

[Kevin Brosnan (kbrosnan)]

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

[CobraBKeX (cobrabkex)]

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.

[Mozilla-bugs-nogin (mozilla-bugs-nogin)]

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.

[Nickolay Ponomarev (asqueella)]

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.

[Srcmax (srcmax)]

> 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

[Launchpad Janitor (janitor)]

This bug was fixed in the package firefox - 3.6+nobinonly-0ubuntu1

---------------
firefox (3.6+nobinonly-0ubuntu1) lucid; urgency=low

  * New upstream release v3.6 (FIREFOX_3_6_RELEASE)
    + fix LP: #449744 - Firefox crashes when attempting to load Firebug 1.5
    + fix LP: #66015 - Duplicate spell checking dictionaries for every entry
    + fix LP: #132938 - tooltips dont work in sidebar
    + fix LP: #195698 - Password asked separately for each tab that requires it
                        (proxy)
    + fix LP: #239462 - tooltips disappear too fast
    + fix LP: #385816 - Resize corner grab stays visible after maximize
    + fix LP: #429476 - firefox crash on javascript page
    + fix LP: #432876 - Icons missing in Firefox searchbox drop down list
    + fix LP: #486284 - maxlength on input box can be overriden by autocomplete
    + fix LP: #501393 - Integrate Firefox notifications with notify-osd bling

  [ H. Montoliu <email address hidden> ]
  * fix LP: #361052 - firefox apport hook fails to retrieve pluginreg.dat file
  * update debian/apport/firefox-3.6.py - removed unused code and minor refactoring.

  [ Fabien Tassin <email address hidden> ]
  * Update the location of the upsteam branch now that 3.6/Namoroka has its own
    branch, and trunk moved on to 3.7
    - update debian/mozclient/firefox-3.6.conf
  * Use Namoroka instead of Shiretoko as brand name and use it for snapshots.
    Name it Namoroka in the Preferred Application UI too
    - update debian/firefox-3.6-shiretoko.desktop => debian/firefox-3.6-namoroka.desktop
    - update debian/firefox-3.6.xml
    - update debian/rules
  * Target the 'default' branch instead of tip
    - add debian/moz-rev.sh
    - update debian/mozclient/firefox-3.6.conf
  * Add firefox 3.6 to the list of Preferred Applications in Gnome
    - add debian/firefox-3.6.xml
    - update debian/firefox-3.6-gnome-support.install
  * Add ${misc:Depends} to all non-transitional packages, make firefox-3.6-dbg
    depend on firefox-3.6 with the exact same version, move -dbg packges to
    priority extra and add firefox-3.6-gnome-support-dbg
    - update debian/control
  * Update diverged patches:
    - update debian/patches/browser_branding.patch
    - update debian/patches/firefox-profilename
    - update debian/patches/ubuntu_bookmarks.patch
    - update debian/patches/lp185622_system_path_default_browser.patch
    - update debian/patches/dont_depend_on_nspr_sources.patch

  [ Alexander Sack <email address hidden> ]
  * add libnotify-dev to build-depends
    - update debian/control
  * add libiw-dev to build-depends to fix build failure
    - update debian/control
  * until we move searchplugins to a separate package provided only by the current default
    firefox, we need to make firefox-3.6 replace all the older firefox binary packages:
    firefox-3.5, firefox-3.2, firefox-3.1, firefox-3.0
    - update debian/control
  * implement MIN_SYS_DEPS approach that does not use system xulrunner
    and only a minimal set of system dependencies.
    + drop patches not required anymore:
      - delete debian/patches/dont_depend_on_nspr_sources.patch
      - update debian/patches/series
    + update browser directory provider...

[Paul-oshannessy (paul-oshannessy)]

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

[Mats Palmgren (matspal)]

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

[Matti-mversen (matti-mversen)]

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

[Matti-mversen (matti-mversen)]

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

[Ria-klaassen (ria-klaassen)]

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

[Peter Gervai (grin)]

I believe this has been fixed quite a while ago.

[Sidhanti Sudheendra (sidhanti157)]

Didn't realize this ticket was still open. You can go ahead and closer it.

On Fri, Mar 13, 2015, 17:35 Peter Gervai <email address hidden> wrote:

> I believe this has been fixed quite a while ago.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (239311).
> https://bugs.launchpad.net/bugs/195698
>
> Title:
> Password asked separately for each tab that requires it (proxy)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/firefox/+bug/195698/+subscriptions
>