User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060530 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060530 Minefield/3.0a1 When sessionstore is enabled (browser.sessionstore.enabled -> true) and a authentication proxy is used FF opens multiple login request windows. Seems that multiple requests are sent simultaneous to the proxy before the login is completed. I have one homepage and two RSS feed and i get literally dozens of login requests and the FF window is flickering until the login is completed. If there are multiple request sent at that time it may be better to send them in sequence if a proxy is configured. It is slower than multiple requests but possibly entering the login data or simply pressing the OK button multiple times is much more annoying. Reproducible: Always Steps to Reproduce: 1. Have an authentication proxy 2. Have session store enabled (browser.sessionstore.enabled -> true) Actual Results: Multiple login requests are shown Expected Results: Only one request should be shown.

I can confirm the behaviour. Here I've set two external sites as 'home group' in Minefield. Each time I fire up MF it's asking twice to log-in to the proxy. (OS in my case is Windows XP SP2)

If you have multiple homepages in 1.5.0.x, do you get multiple proxy auth dialogs? I don't think sessionstore is doing anything different from the multiple homepage case.

(In reply to comment #2) > If you have multiple homepages in 1.5.0.x, do you get multiple proxy auth > dialogs? I don't think sessionstore is doing anything different from the > multiple homepage case. I'm using on the same machine FF 1.5.0.4, FF 2.0a3 and FF 3.0a1, all with the same exxtensions and nearly the same prefs.js. In all profiles I've set the same pages as 'home group', three of them in the corporate intranet two from the internet, to be reached via a proxy. In FF 1.5 as well as in FF 2.0 I only get asked once to log on after starting FF. In FF 3.0 each time I get asked twice to log-on to the proxy plus some sort of 'window' I cannot describe but with a screenshot (s. attachment).

I can confirm this bug, happens to me as well, either restoring session or with multiple homepages. Randomly, Fx gets stuck and doesn't even ask for some of the passwords so the page(s) doesn't load. The small window shown in comment #3 (https://bugzilla.mozilla.org/show_bug.cgi?id=339804#c3) stopped appearing for me long ago, and instead I get windows asking for a username and password, without any text or indication to indicate what site it is related to. I have Fx configured to remember passwords, don't know if it has to do with it. Maybe someone who sees this and doesn't have Fx remember passwords can shed some light on this issue.

I guess this issue parallel to the password prompt issue in bug 348997 which rather seems to be a core bug (bug 369963) in that the same prompt is not reused for several tabs if one's already open. Please file an appropriate core bug (and mark it as blocking this one) if you can reproduce the following behavior: 1. Set Firefox to launch with a blank page. 2. Open an URL which triggers a proxy authentication prompt (don't fill anything in). 3. Launch the same URL from an external source (e.g. by entering it into Start -> Run... if Firefox is your default browser). Now you should have two proxy authentication prompts open although one such prompt would be sufficient for both pages.

No, it doesn't work like that for me. If I do what you have in your testcase, Firefox works as expected, and only one prompt is showed. What happens to me is that I have a local html that opens two different pages on different frames, both from the same site that requires authentication. If you navigate the site, you have to authenticate only once to see both pages and many others; however, if I open my local html page, it will ask for a username and password twice, and I guess it would be n times if I had n frames from that site.

This bug still persists in the actual Gran Paradiso Alpha 4 pre version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070426 GranParadiso/3.0a4pre ID:2007042613 [cairo] Scenario I've set Gran Paradiso to 'When Gran Paradiso starts: Show my home page' Home page: intranet/1|intranet/2|intranet/3|internet/1|internet/2 The pages 'internet/1' and 'internet/2' can only be reached via a proxy (automatic proxy configuration through proxy.pac). After firing up Gran Paradiso each time I get asked twice to authenticate to the proxy. One can see by the progress bar that after the first log-on only the first internet page starts to load and only after the second log-on the second internet page starts to load. Clean and empty profile, no extensions. Whether or not I have "user_pref("browser.sessionstore.enabled", false);" in my prefs.js does not matter at all.

We need to investigate this more deeply.

(In reply to comment #12) > We need to investigate this more deeply. Firewalled as I am and suffering from this bug I'd be glad to help if possible.

The regression window is between these two builds: doesn't work: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/05/2006-05-10-13-trunk/ works: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/05/2006-05-10-02-trunk/ And seeing some %proxy% filenames in bonsai, I'd say its one of these checkins: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-09+00%3A00%3A00&maxdate=2006-05-11+00%3A00%3A00&cvsroot=%2Fcvsroot ;)

Is this behavior the same bug? When I use the "Open all in tabs" to open several windows each of which has a password, I am prompted to enter the Firefox password manager password once for each window. I would expect a single login to password manager would be enough. FF2 works as I would expect. All the nightlies for the last few months have requested the same password multiple times.

The behavior is independent of the session restore flag.

I'm using Firefox behind a corporate proxy (configured via PAC file) that requires HTTP authentication to grant Internet access. With a freh new profile I encountered different bugs: 1) at the first start I get a "Networw Timeout page" due to non-yet-configured proxy (Bug 218944 - Bug 257664 - Bug 310331); 2) I put my automatic proxy configuration URL in Tools - Options - Advanced - Network - Settings (six clicks away from the Network Timeout page??!!) and restart Firefox; 3) at the 2nd start Firefox ask me about proxy auth and Password Manager ask me to save proxy auth: I confirm both requests; 4) go to Tool - Add-ons and install one of the "Reccomended extensions" (it doesn't matter what extension) and then re-start Firefox; 5) at the 3rd start Firfox open two windows asking proxy auth confirm twice (see proxy_auth_1x.png and proxy_auth_2x.png). So this bug is definetely not yet fixed and worse items 1 and 2 needs some developer attention. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre.

This page http://sivel.net/2007/05/firefox-ntlm-sso/ helped me setup Firefox to eliminate a lot of my NT Login prompts. Now I only have two or three prompts when I restore a session instead of one per tab. The only issue I had with it was knowing what the list of http login prompts were, but I would just copy them from the dialog boxes and paste them into the list. Hope this helps someone.

This is still present in RC2 and is extremely annoying if you are saving your tabs from one session to the next (which is now a much more explicit option than in FF2), or Firefox restarts after add-on or update installation and you are then presented with 10 subsequent requests for the master password plus 10 requests for the proxy authentication. In a corporate environment, FF is seriously broken unless this gets fixed.

This bug is certainly annoying and makes my Firefox experience horrible, especially if I'm deep into a session with a dozen or so tabs open and Firefox crashes. Yes, Firefox nicely offers to restore my session, possibly lowering the frustrating of loosing all my current works and layout, however, I then get prompted a dozen prompts all wanting my proxy username/password. It's very frustrating. Opera handles the same issue much more gracefully.

(In reply to comment #30) > This bug is certainly annoying and makes my Firefox experience horrible, > especially if I'm deep into a session with a dozen or so tabs open and Firefox > crashes. Yes, Firefox nicely offers to restore my session, possibly lowering > the frustrating of loosing all my current works and layout, however, I then get > prompted a dozen prompts all wanting my proxy username/password. It's very > frustrating. Opera handles the same issue much more gracefully. > If you've lots of tabs open via a proxy, enter the password at the first prompt then hit 'esc' for all the others. If you refresh the failed logins to the proxy, you may (hopefully) get the pages you were at before - at least it works that way for me (-; Still anoyying, but much easier than passwords/usernames for all of them (if you've got youre passwords password protected or the proxy password isn't stored - otherwise you could hit 'enter' for each..)

(In reply to comment #31) > *** Bug 438307 has been marked as a duplicate of this bug. *** > Thanks Jo for doing our housekeeping ;-)

A vast majority of companies use HTTP proxies. This behavior from FF would at best appear to the average user to be a bug, and at worst they will think their computer is broken (virus, trojan, etc.). This bug is a complete show stopper for any serious enterprise deployment.

This bug is really annoying. I do have a company proxy that requires authentication and I usually open at least 6 tabs once I restore FF. Having six proxy authentication dialogs is not really a pleasant thing to have. Cheers.

maybe also related to bug 230190 ? reproducable with FoxyProxy addons rules when using multiple proxies.

This is so annoying. I love Firefox, but this simple bug keep me asking myself if it is worth the frustration i feel. I use a stunnel proxy connection. I do a lot of research and have often more than 20 tabs open at the same time. If I close down Firefox and reopen. I allways get at least 20 password boxes to respond to (as many as number of tabs). Of course I escape all but the first, and then refresh all, but it is still really annoying. Especially when firefox also updates 1-4 extensions at the same time and put up other smaller password boxes also. I of course use NoScript so it happens every day. Firefox also seems to chrash much more often when using proxy than normally.

I've been suspending my machine overnight - my proxy sessions stay active (ie: not login prompts when I wake up :). This comment may help too: (In reply to comment #27) > This page > http://sivel.net/2007/05/firefox-ntlm-sso/ > helped me setup Firefox to eliminate a lot of my NT Login prompts. Now I only > have two or three prompts when I restore a session instead of one per tab. > The only issue I had with it was knowing what the list of http login prompts > were, but I would just copy them from the dialog boxes and paste them into the > list. > > Hope this helps someone.

:-( How depressing that this bug has been open for 2.5 years now. Just sayin'...

I also experience this bug under Firefox version 3.0.3 with Ubuntu Linux version 8.04 (Gutsy Gibbon). Usually it displays one proxy authentication dialog for each server it gets content from, and occasionally one per item to be loaded (even when they're from the same server, though this is random and I haven't experienced this very many times due to recently switching to FF3).

It's gotten worse for me, at least apparently. The first time I used FF3, it would pop up a login dialog for each tab. Now it pops up a dialog for each connection loaded in the tag. Seriously, I'll log into the proxy for a site that uses a bunch of AJAX, and then 10 more login dialogs will pop up, one per AJAX connection. Sometimes a 5 tab session requires more than 25 login dialogs! I've started just hitting "cancel" on a bunch of those dialogs,and then hitting 'reload' on the tabs.

C'mon folks! This is a serious bug that's been open for 2.5 years and no one is even assigned to work on it?

Well I don't have the expertise to correct the bug itself, but I can offer a fairly decent work around solution. I have installed the Session Manager add-on. Then when I start FF I tell it not to restore the windows from the previous session. Then I open one window so that the proxy authentication takes places. The last stop is to go to the Tools / Session Manager menu and restore the most recent saved session. It's not as good as the bug being fixed, but it is way better than having to click on 50 dialog boxes!

Asking for wanted 1.9.1. I think it'd be a huge usability win to get this fixed, if we can. I remember this coming up during a UI meeting a few months ago and all of us sharing our work-arounds for this when Beltzner said, if there's something we have tons of workarounds for, that's something we should fix. I agree. Can we fix this in 1.9.1?

TO ALL COMMENTATORS Actually, there is a workaround for this bug that DO WORK form me: AutoAuth extension ==> https://addons.mozilla.org/en-US/firefox/addon/4949 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Indeed, thanks RNicoletto :-)

Yes I confirm that AutoAuth is a workaround. Unless you also have the Security/Use a master password option enabled, in which case FF goes into an infite loop and you have to kill it and disable the option to get it working.

(In reply to comment #55) > Yes I confirm that AutoAuth is a workaround. Unless you also have the > Security/Use a master password option enabled, in which case FF goes into an > infite loop and you have to kill it and disable the option to get it working. So not really a viable workaround. Workarounds for bugs that are older than 2 years is just plain lame though. mozilla-devs: can we hold up on the destabilizing features a second and fix some very old very visible user interface bugs, like this one and the constant crashes in GCGraphBuilder::AddNode (bug 460916) and the lord knows how many crashes in Flash. Please. Eye candy ain't so sweet when you keep choking on the candy.

To add to my previous comment, there are <sarcasm>only</sarcasm> 86 people being CC'd on this bug and 43 votes to fix it. I wonder how that ranks in the grand scheme of user reported bugs.

People who can't wait for the fix, maybe you could consider paying someone to do it? That's also how OpenSource works: we could pay someone together to concentrate especially on this bug. 43 (or even 86) x 10 dollars might be enough to push someone to look at it... IMO, that's how OS works: either wait or do something by yourself. I guess some of the people that've just been ranting here are developers. Why don't just propose/attach a patch to this bug? Please, do not forget contributing is the foundation of OS, so that's the same thing for Firefox. You should contribute by giving money, time or anything useful, but don't rant against Moz developers as if they were outsourcers paid by you, I find it quite dishonest... Cheers, everybody. PS : AutoAuth works just plain great for me. But I don't use master password, granted. Btw, if there's a problem with the master password with AutoAuth, shouldn't you file a bug in its tracker instead of complaining here?

I'd definitely pay for this too (although AutoAuth works for me as already stated). This means we have to find someone to do it and the funds to pay said person. Is there a recommended method to do this with some basic guaranties in order to prevent somebody from running away with the money?

As individual I am ready to pay 10-15 USD for this bug fixing.

(In reply to comment #1) > I can confirm the behaviour. Here I've set two external sites as 'home group' > in Minefield. Each time I fire up MF it's asking twice to log-in to the proxy. > (OS in my case is Windows XP SP2) Does anyone listening to this bug know of a way to organise such communal payment? Something like: contributors pay into a temporary account which is then released to a developer when the bug is fixed. Bugzilla provides a forum for deciding when a fix is finished (how to divide the funds if there are multiple commits?). Perhaps a time limit (perhaps long..) could be introduced, after which contributors get their money back?? Does pay pal provide anything like that?? I'd be willing to pay some for the fix too..

I really hate being a dick about these sort of things, but I wonder how many people have to pile on to this bug before it's seen as important enough to work on. Hold the "features", devs, and work some bugs please. Eye candy loses is appeal real quick when things crash and annoy.

(In reply to comment #61) > > I'd be willing to pay some for the fix too.. I'll put in $20

(In reply to comment #59) > Is there a recommended method to do this with some basic guaranties in order to > prevent somebody from running away with the money? Not as far as I know, so there is not much point in making pledges in the bug comments. Adding more comments doesn't get more attention for the bug, it just makes things messy. If someone wants to coordinate pledges or advocacy, then that should happen in a forum or newsgroup or somewhere else...

I'd also really like to see this fixed asap. I tried AutoAuth as mentioned above but it didn't work for me; I'm not sure why (my proxy uses NTLM).

Not blocking as it's not a new regression, though I agree that it's unfortunate. This is a broad issue (we also, AIUI, run into this type of problem on session restore in a few other places) that needs more time to work out. Dolske: can you add dependencies / related bugs?

it seems there is a similar issue when you load multiple page which are protected by the same realm / htaccess: you get a login/pass window for each page. Related bug i found: 230190, 339804, 430287

I am being affected by this annoying behavior also in a corporate environment where a basic auth is needed for the http proxy. Just want to point out that all the Authentication windows are modal dialog, and that you have to click/close/OK each one in specific order! I have had problem that the dialogs order get messed up (for reason I don't know) every now and then and I end up having the need to 1) move the dialogs side by side and try to see which order it is! 2) kill firefox all together because it keeps on flicking overloading my system! Before the problem is solved, I would appreciate any workaround. pressing ESC for all of them won't work in the above case because of wrong order of the modal dialogs. Thx

(In reply to comment #68) > > Before the problem is solved, I would appreciate any workaround. pressing ESC > for all of them won't work in the above case because of wrong order of the > modal dialogs. Thx Have you tried autoauth: (In reply to comment #53) > TO ALL COMMENTATORS > > Actually, there is a workaround for this bug that DO WORK form me: AutoAuth > extension ==> https://addons.mozilla.org/en-US/firefox/addon/4949 > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 > Firefox/3.0.4

did anyone (developer) start work on fixing this bug forever?

3.0.6 is worse for some reason. I had 12 tabs open when I restarted this morning and I had 20 requests for the proxy password : ( AutoAuth 1.3 which is the current version from the add-ons page doesn't work on page load, and I am unable to access options to set passwords anyway.

> I had 12 tabs open when I restarted this > morning and I had 20 requests for the proxy password : ( I regularly see this behaviour plus I have a master password set so I get a prompt for the master password everytime as well :-( I think there is at least one password request for each open tab plus requests for every extension that is installed as FF wants to check if there are any updates available. I suspect the startup sequence is fetching stuff in parallel in order to start quicker which fails for users behind a proxy. If that's the case the startup sequence needs to be modified to fetch the first tab/or check first extension update and *cache credentials* (master password and proxy) and then fetch the rest in parallel. This will slow the startup down for non proxy users and return usability for the rest of us. Another solution could be to create a flag preference "behind_proxy_server" and if it is set then FF first prompts for what it needs, caches it and then does everything exactly the same...

> I suspect the startup sequence is fetching stuff in parallel in > order to start quicker which fails for users behind a proxy. If > that's the case the startup sequence needs to be modified to fetch > the first tab/or check first extension update and *cache > credentials* (master password and proxy) and then fetch the rest in > parallel. As far as I can tell, that's correct. The browser fires off an http request for each open tab plus one for each installed extension (presumably an update check). I took a preliminary look at the code, and I believe the cacheing of credentials is already correct (that's why you don't need to re-enter for every http request). What's needed is to block new http requests if there's an existing request waiting on authentication. This isn't particularly easy, since the authentication is asynchronous. I made some attempts to code this up by I wasn't successful, but I don't know the code base and honestly don't have much experience with multi-threaded applications. I suspect if we can get the attention of someone who really understands the networking code they can make the appropriate fixes (at least to the http code) fairly easily.

> The browser fires off an http request for each open tab plus one for > each installed extension (presumably an update check). I'm going to have to mea culpa on that "one for each installed extension". After further investigation, it appears that Ubiquity fires off a raft of http requests upon startup, probably coincidentally the same number as I have extensions installed. Without Ubiquity installed, I get a request for each open tab as expected.

Shouldn't it be possible to have a single mutex[1] somewhere in the code that pops up an authentication dialog so only one thread can show it at a time? Something like this may do the trick: If we need to authenticate and haven't already: request a lock on the mutex if we haven't authenticated yet: show dialog and do authentication end if unlock mutex end if The pair of checks would be to ensure that we don't need to use the mutex when we've already authenticated, leaving the speed as it is and only blocking things during start up. However, I don't know how you'd do that in Firefox's source code... [1]: http://en.wikipedia.org/wiki/Mutual_exclusion

Shouldn't it be possible to have a single mutex[1] somewhere in the code that pops up an authentication dialog so only one thread can show it at a time?

> Shouldn't it be possible to have a single mutex[1] somewhere in the > code that pops up an authentication dialog so only one thread can > show it at a time? You'd think :-). That's in fact what I was/am working on, but suffice to say that it isn't as easy as I expected. Just getting Firefox to build is an adventure -- very little documentation and much of it wrong, for one thing.

(In reply to comment #77) > You'd think :-). That's in fact what I was/am working on, but suffice > to say that it isn't as easy as I expected. Just getting Firefox to > build is an adventure -- very little documentation and much of it > wrong, for one thing. Hang out on irc.mozilla.org and you'll get lots of help with building Firefox. There are decent instructions on MDC, too, but you didn't say which platform and compiler you're using so I can't point you to the right doc.

(In reply to comment #78) > (In reply to comment #77) > > You'd think :-). That's in fact what I was/am working on, but suffice > > to say that it isn't as easy as I expected. Just getting Firefox to > > build is an adventure -- very little documentation and much of it > > wrong, for one thing. > Hang out on irc.mozilla.org and you'll get lots of help with building Firefox. > There are decent instructions on MDC, too, but you didn't say which platform > and compiler you're using so I can't point you to the right doc. (In reply to comment #78) > (In reply to comment #77) > > You'd think :-). That's in fact what I was/am working on, but suffice > > to say that it isn't as easy as I expected. Just getting Firefox to > > build is an adventure -- very little documentation and much of it > > wrong, for one thing. > Hang out on irc.mozilla.org and you'll get lots of help with building Firefox. > There are decent instructions on MDC, too, but you didn't say which platform > and compiler you're using so I can't point you to the right doc. So, what would be the right document to use as far as fixing this issue goes putting aside the aspect of building firefox?

(In reply to comment #82) > So, what would be the right document to use as far as fixing this issue goes > putting aside the aspect of building firefox? I'm not sure I understand the question. What you need to do is to hunt through the code to identify where the proxy connection is being opened (prompting the dialogue to enter your username/password) and then wrap that with some sort of mutex to keep from re-entering it until the first dialogue completes. If you're serious about tackling it, email me and when I get a chance I'll get on my development machine and point you toward what I identified as a starting point. (Could be wrong though, as I could never get it to work.)

I got to know that this bug is going to be fixed by another bug. Thanks for the response Scott (In reply to comment #83) > (In reply to comment #82) > > So, what would be the right document to use as far as fixing this issue goes > > putting aside the aspect of building firefox? > > I'm not sure I understand the question. What you need to do is to hunt through > the code to identify where the proxy connection is being opened (prompting the > dialogue to enter your username/password) and then wrap that with some sort of > mutex to keep from re-entering it until the first dialogue completes. If > you're serious about tackling it, email me and when I get a chance I'll get on > my development machine and point you toward what I identified as a starting > point. (Could be wrong though, as I could never get it to work.)

I got to know that this bug is going to be fixed by another bug. Thanks for the response Scott (In reply to comment #83) > (In reply to comment #82) > > So, what would be the right document to use as far as fixing this issue goes > > putting aside the aspect of building firefox? > > I'm not sure I understand the question. What you need to do is to hunt through > the code to identify where the proxy connection is being opened (prompting the > dialogue to enter your username/password) and then wrap that with some sort of > mutex to keep from re-entering it until the first dialogue completes. If > you're serious about tackling it, email me and when I get a chance I'll get on > my development machine and point you toward what I identified as a starting > point. (Could be wrong though, as I could never get it to work.)

Bug 475053 will fix this problem.

FoxyProxy Plus 3.1 resolves this issue by allowing you to enter proxy authentication details just once. Screenshot: http://foxyproxy.mozdev.org/fpplus/images/screenshots/current/auth.png More info: http://foxyproxy.mozdev.org/fpplus/

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090718 Shiretoko/3.5.1pre (.NET CLR 3.5.30729) The behavior of this is still not quite right. If you have add-on updates, you get prompted for the proxy password to download the updates and then again when the browser starts up. Admittedly this is a minor inconvenience (particularly compared to the old behavior).

As per comment 86, bug 475053 landed on trunk. Anyone experiencing this bug is invited to test latest trunk (possibly with a clean profile) and report results here.

Fixed by bug 475053.

Can someone please test the fix with a recent Minefield build which can be found here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ Thanks.

For me, it works good with trunk from last week (only 3 password windows with 2 proxies handled by foxyproxy compares to ten and a lot more before) thanks a lot

Thanks Julien. For anyone else please take care that the mentioned build in comment 93 is a development build. So you should run a test in another profile.

For me it works. But it seems this is because new firefox saves page-data locally and does not connect to the proxy for restoring the session.

this isn't just when there is a proxy involved, it's any time you have a site doing basic auth and mange to open multiple sessions to that site before completeing any of the authentication dialogs. a similar problem happens if you set cookies to 'ask', it can create lots of popup dialogs, they can get out of order, and even if you do something in one that will approve/deny cookies for the entire site you still have to hit all the other dialogs manually. see bug 516224

(In reply to comment #98) > this isn't just when there is a proxy involved, it's any time you have a site > doing basic auth and mange to open multiple sessions to that site before > completeing any of the authentication dialogs. This bug was fixed by bug 475053 "Implement asyncPromptAuth to fix multiple HTTP/proxy password prompt overlap". That title might explain it.