User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5 On visiting a page which contains images which require http-auth, Firefox 2 would properly prompt the user for credentials once, and if successful, use them to load all the images. Firefox 3.0b5 is prompting me once for every image on the page, even though they all have the same auth realm. Reproducible: Always Steps to Reproduce: I've provided a test site in the URL field.

I can confirm the issue. I found similar "multiple prompts" bugs, but this one seems to be different. Bug 348997 – Session restore causes multiple prompts for same password Bug 356097 – Master password prompted multiple times on start-up for proxy authentication Bug 95397 – Mozilla should not ask the same question in more than one window. I'm wondering why it didn't prompt multiple times on Firefox 2, as bug 95397 existed at the time.

this bug is brought to you, courtesy of nsIThreadManager

This should be a dupe of bug 385239. It happens each time multiple items need HTTP auth.

That's similar but I wouldn't mark it as a duplicate. Canceling the multiple prompts when clicking Cancel would solve half of the issue. You also need not to prompt again after a successful login (when clicking on Ok). I guess that fixing this bug should fix bug 385239 too.

Max, Could you provide the credentials, so we could reproduce ?

Serge, username=x, password=x (as stated in the dialog).

Here's an additional detail that I've just noticed: Firefox 3 is opening all the prompt dialogs immediately on page load - i.e. if you drag the active prompt dialog around, you can see that all the others are already open in a stack of windows. So, whilst it looks like firefox is prompting 10 times in series, it's actually launching all the prompts in parallel. I guess some sort of locking is required to serialize Firefox's interaction with the user.

And it looks like something's definitely broken in the UI interaction threading, since once you've dragged these boxes around the screen, it turns out you can only cancel them in the exact order that they popped up in.

Following are similar "multiple prompts" bugs for proxy. > Bug 339804 Multiple login requests for authentication proxies if sessionstore is enabled > Bug 382789 Proxy password is asked for every object

Just wanted to voice my vote for making this bugfix a priority. This issue is currently a show-stopper for FF3 deployment in my organization. In our intranet, we use basic authentication to protect certain image resources, which are linked from another auth realm that provides the "gallery" page indices. Browsing to those gallery pages with FF3 instantly produces literally dozens of authentication dialog instances, which we've found to be extremely confusing to our users.

Regressions from the thread manager are wanted, but not sure who can own this. Regardless, this should be looked at for 1.9.1.

This bug must be fixed. It can be used for a DoS, see: http://sarsie.fobby.net/explode.php [caution: will most likely crash FF3, and Opera as well] This should have been obvious from the start, in the betas. Or is the Mozilla Foundation only interested in fixing security bugs once they're exposed as such to save face?

(In reply to comment #13) > This bug must be fixed. It can be used for a DoS Crash and DOS bugs (ones which can't be exploited to run arbitrary code or perform privileged actions) aren't as serious as you think, nor are they security vulnerabilities. If a page causes a crash, the user just doesn't visit it, and that's all there is to it. It's important to fix it, sure, but just because it causes a crash doesn't ipso facto make it must-fix-immediately. What matters is how often users will encounter it in daily browsing; in particular, your synthetic crashing testcase (didn't actually test, assuming what you say is generally true and not just true for you) is very much not representative of sites one might find in typical browsing. (There's certainly something of a chicken-and-egg problem regarding the relatively benign problem that was originally reported here, to ignore your crash testcase for a moment. However, as the functionality enabled by fixing the bug isn't of particularly high value, the chicken-and-eggness isn't all that relevant to evaluation of this bug's importance.) > Or is the Mozilla Foundation only interested in fixing security bugs once > they're exposed as such to save face? Bad-faith insinuations don't generally make people listen and respond to complaints. Also, see above; without evidence that this can be used to run arbitrary code, get around the same-origin principle, or access privileged data (to name a few possible reasons), this is not a security bug.

(In reply to comment #14) > (In reply to comment #13) > > This bug must be fixed. It can be used for a DoS > > What matters is how often users will encounter it in daily browsing; in > particular, your synthetic crashing testcase (didn't actually test, assuming > what you say is generally true and not just true for you) is very much not > representative of sites one might find in typical browsing. I encounter this daily, though it's a self inflicted DoS. For my web hosting company I create graphs of the servers' performance. These graphs are protected by http basic auth. I link those images from an internal wiki. I've got about 50 images linked in one page. When I forget to log into the directory containing the images, I effectively DoS my browser when visiting the wiki. It's almost impossible to close all password dialogs, forcing me to kill the browser. This is *the* number one bug I'd like to be fixed in firefox.

If you define a "security bug" to not include DoS'ing, of course it's not a "security bug". DoS bugs this simple ARE serious, as they can be triggered by otherwise benign configurations rather than outright malicious coding. They waste time, and sometimes work. They cause aggravation. Certainly they're not to the level of code execution or unprivileged information access, but still... This bug, though not taken to the extreme of causing a crash, has come up for me with daily browsing(some with HTTP AUTH, mostly with cookie confirmation, which isn't exactly the same bug and won't affect as many people, but likely has the same underlying cause). > Bad-faith insinuations don't generally make people listen and respond to > complaints. Being non-confrontational hasn't worked well for getting serious FF regressions and bugs fixed either, in my experience. Perhaps I'm just cynical.

(In reply to comment #15) > I encounter this daily, though it's a self inflicted DoS. For my web hosting > company I create graphs of the servers' performance. These graphs are > protected by http basic auth. I link those images from an internal wiki. Heh, that's the exact same use-case as for me :-) > This is *the* number one bug I'd like to be fixed in firefox. Ditto!

Agreed. This is also by far the number one Firefox bug for me. As I mentioned in my previous comments, this is the one (and only) issue that is preventing my organization from rolling out Firefox 3 to replace Firefox 2. The thing that bothers me the most about the developers' seeming lack of concern is that this isn't asking for a new feature--it's asking to fix a *regression* bug that wasn't present in previous versions.

Not sure this is the best approach... basically it bails out of GetCredentials() if it needs to prompt while there's an auth prompt already in progress. When the in-progress prompt is done (and cached as necessary), it tries again. Patch is kinda rough and testless, but curious if bz or biesi (or anyone else) has any thoughts on a better approach...

Doesn't the patch in bug 475053 fix this?

Comment on attachment 362192 [details] [diff] [review] wip Looks like it.

Probably dup of bug 387652 that also deps on bug 475053?

I agree, marking as such.