Closed Bug 348997 Opened 18 years ago Closed 15 years ago

opening multiple tabs can cause multiple prompts for same password (e.g. when using Session Restore)

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: bugzilla, Assigned: mayhemer)

References

Details

(Keywords: regression, verified1.9.2, Whiteboard: [fixed by bug 475053])

Attachments

(6 files, 5 obsolete files)

Messed up "sheet" rendering a window useless until restart.
72.08 KB, image/png
Details
Loading 6 Tabs in New Profile (no Addons) with Master Password shows 3 prompts
100.29 KB, image/png
Details
OSX Session Restore using TabMix Plus shows random blank entry
145.42 KB, image/png
Details
screenshot of issue in action
110.64 KB, image/jpeg
Details
Patched fedora 9 firefox 3.0.1 with 3 master password dialogs
209.02 KB, image/png
Details
screenshot after installing 3.0.5 (Win)
85.93 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060816 BonEcho/2.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060816 BonEcho/2.0b1 If I have several tabs open on a site that uses HTTP Basic authentication or similar, then each tab will prompt for a username and password when the session is restored. I have to fill in the username and password for each tab otherwise it will fail to load. This also occurs if I have a master password set. I have to enter the master password for each tab on the site. It seems the problem is that all the prompts appear at once, one in front of the other. If only one prompt appeared at a time (per window), then a second prompt would not appear for a site that had already been logged into. Reproducible: Always Steps to Reproduce: 1. Enable session restore from options 2. Open two tabs on a site that has HTTP Basic authentication 3. Restart browser Actual Results: Password is asked for twice Expected Results: Password is asked for only once
I made a simple test case that I could link to for people to try out, but for some reason it did not trigger this bug. This test case is here: http://www.stonie.co.uk/firefox/testcases/password/ The username and password is 'test'. However, I can still reproduce this on several real world sites I use. I will need to investigate a bit to find out what's causing this.
Version: unspecified → 2.0 Branch
*** Bug 359878 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
WFM using latest branch on Mac. Loaded 2 tabs, each with your example URL. Restarted browser with session restore enabled. I got prompted for credentials only once, and after entering them, both tabs loaded fine. Hm, I'd wonder about platform difference, except justdave is also on Mac...
try having different sites in the different tabs. It may also require multiple windows rather than just multiple tabs. Most of the times I've run into it I've actually had multiple windows open (with multiple tabs in each). Some in intranet, some in nagios, some in the internal sysadmin wiki, etc.
*** Bug 362660 has been marked as a duplicate of this bug. ***
Component: Tabbed Browser → Session Restore
QA Contact: tabbed.browser → session.restore
Depends on: 369963
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.
FYI all - I've run into this consistently, though I have Nagios as well as a number of passworded wiki sites (many different hosts) each asking for passwords. I frequently have to wait for Firefox to start and load all pages except password protected pages, then begin typing passwords. What a pain in the backside.
I believe this to be a bug in the security portion of Firefox as the problem has been around long before the Session restore functionality was added. See bug 225710 for the first documented bug I could find on it (nearly 4 years ago). Bug 369963 is pretty much the same bug, just opened more recently on it.
Just a thought, but would it be possible to open the password manager dialog to receive the master password BEFORE any of the tabs are initialized so that saved passwords can be put into the authentication dialogs as they appear? Still annoying to have to go through and click Okay on all those dialogs (of course this is another issue) but one heck of a lot better than this startup horror that I have to endure every time I open firefox.
(In reply to comment #13) > Just a thought, but would it be possible to open the password manager dialog to > receive the master password BEFORE any of the tabs are initialized so that > saved passwords can be put into the authentication dialogs as they appear? While it would be possible to ask for the master password in advance, we can't tell whether we'd actually need it. For my part, I'd be quite annoyed to enter the master password at every startup even when it's not needed at all (especially since we also restore cookies which in many cases make it unnecessary to re-login).
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.
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?'.
I hit this bug also.
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...
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.
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
Blocks: 95397
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.
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.
(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).
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
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]
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.
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).
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.
Flags: blocking-firefox3?
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.
Flags: blocking-firefox3? → blocking-firefox3-
(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.
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.
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.
Flags: blocking-firefox3- → blocking-firefox3?
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).
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.
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
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.
This is *exactly* the situation I find myself in, and the thought of restarting Firefox (after an update for example) is unbearable.
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.
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.
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).
Assignee: nobody → kengert
Status: REOPENED → NEW
Component: Session Restore → Security: UI
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: session.restore → ui
Version: 2.0 Branch → unspecified
renominating blocking since the component move killed it.
Flags: blocking1.9?
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 == ??
fips == Federal Information Processing Standard (FIPS) preferences->advanced->security devices->enable fips mode
This is not a regression from Fx2, not a blocker.
Flags: blocking1.9? → blocking1.9-
This may not technically be a regression, but it is much worse in Fx3 than it was Fx2.
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.
(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
Flags: blocking1.9.0.1?
Keywords: regression
(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...
Oh, I guess there's no such blocking flag yet. :-)
(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
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.
This is a RIDICULOUS blocker, and when I turn on the McAffee SiteAdvisor extension I get the weird blank password prompts too.
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.
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).
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?
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.
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).
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.
(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).
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.
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.
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.
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.
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.
Whiteboard: summary in comment 77
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).
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).
(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.
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.
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.
Whiteboard: summary in comment 77 → summary in comment 77, proposal in 82
(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...
Could we simply not spin the event loop while we're showing a modal prompt?
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.
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.
Niels, there's app-modal and window-modal. We don't want these dialogs to be app-modal.
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.
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.
I any case, I think I answered the question in comment 84...
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.
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.
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.
(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.
>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.
--> me, going to work on this.
Assignee: kaie → honzab
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.
Attachment #326384 - Flags: review?(kaie)
Attachment #326384 - Flags: review?(cbiesinger)
Attached patch Improovment to prompt service (obsolete) — — Splinter Review
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.
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.
Flags: blocking1.9.1+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Attachment #326390 - Flags: review?(cbiesinger)
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.
Added a screenshot of the issue in action
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.
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.
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 ;)
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.
(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.
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.
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...
And yes, I did setup a master password!
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.
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?
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 **** 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 **** ALREADY. This isn't even CLOSE to new. Makes me pine for phoenix.
Thanks Michal's work on bug 387652 I could fix bug in the patch. This is fixed version.
Attachment #326384 - Attachment is obsolete: true
Attachment #329486 - Flags: review?(kaie)
Attachment #329486 - Flags: review?(cbiesinger)
Attachment #326384 - Flags: review?(kaie)
Attachment #326384 - Flags: review?(cbiesinger)
Blocks: 387652
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!
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?
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.
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).
One more question: have you also applied attachment 326390 [details] [diff] [review]?
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).
Weee, it really worked! :-) Thanks to all involved!
So is this going to be in 3.0.2 then?
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.
(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).
Status: NEW → ASSIGNED
"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 :-)
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.)
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.
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.
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.
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.
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.
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?
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
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.
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.
(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?
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.
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.
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?
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".
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.
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 ?
It is a FF2 regression. Just check the user agent of the first post. It is FF 2.0b1.
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.
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...
(bug 356097 kind of duplicates this one, or at least should depend on this)
> 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.
Blocks: 177175
No longer blocks: 177175
Attachment #326390 - Flags: review?(cbiesinger) → review?(bzbarsky)
Attachment #329486 - Flags: review?(cbiesinger) → review?(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).
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.
Attachment #326390 - Flags: review?(bzbarsky) → review?(cbiesinger)
Comment on attachment 326390 [details] [diff] [review] Improovment to prompt service 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.
Attachment #329486 - Flags: review?(bzbarsky) → review?(cbiesinger)
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?
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
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.
Installing Tab Mix Plus seems a good workaround for this bug. https://addons.mozilla.org/firefox/addon/1122
@Patrick - except for the twenty bugs that TMP creates after installing. Not a very good workaround in my book.
Passiert hier noch mal irgendwas, oder interessiert dieser Bug die Mozilla-Entwickler wirklich nicht?
Flags: wanted1.9.1?
Flags: blocking1.9.0.1-
Flags: blocking1.9-
Ich nehme an dass Du in Deutsch keine Antworten bekommst... This bug has a blocking flag for FF 3.1.
(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.
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.
(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.
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.
Blocks: 356097
Whiteboard: summary in comment 77, proposal in 82 → [needs review]
This is the same as attachment 326390 [details] [diff] [review], but with the equivalent of "diff -p" added, plus some more context.
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?
You declare and unlock mUserAndPasswordPromptAggregator, but you never seem to use it. I guess you had intended to use it in function nsPromptService::PromptUsernameAndPasswo...
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?
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
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.
Flags: wanted1.9.1?
Whiteboard: [needs review] → [has patch][needs review kaie][needs review cbiesinger]
Version: unspecified → Trunk
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.
- 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.
Comment on attachment 329486 [details] [diff] [review] Fix v2, http channel prompt for identity bypass Please re-request reviews when you have new patches, removing review request. And you might want to mark patches as obsolete.
Attachment #329486 - Flags: review?(kaie)
Whiteboard: [has patch][needs review kaie][needs review cbiesinger] → [has patch][needs review cbiesinger]
Question, are these changes going into the Shiretoko nightly builds?
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...
Comment on attachment 326390 [details] [diff] [review] Improovment to prompt service Approach of this patch is wrong.
Attachment #326390 - Attachment is obsolete: true
Attachment #326390 - Flags: review?(cbiesinger)
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.
Bug 177175 is a duplicate, started 2002-10-28...
Blocks: 177175
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!
(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)
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. :)
Thank you steeve. The StartupMaster Addon fix a problem what no one of the Firefox programmers was able to fix for many months.
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.
(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).
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.
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).
Attachment #329486 - Attachment is obsolete: true
Attachment #356180 - Flags: review?(cbiesinger)
Attachment #329486 - Flags: review?(cbiesinger)
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.
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.
(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)?
Blocks: 436025
Comment on attachment 356180 [details] [diff] [review] v2.1 - http channel async prompting 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*, PromptForIdentityLockInternal*> TPromptLockHashtable; As mentioned I think this should use nsClassHashtable. Why the T prefix? That seems highly unsual in Mozilla code. PromptLockHashtable seems good enough.
Attachment #356180 - Flags: review?(cbiesinger) → review-
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)
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.
I know what the purpose of that style is. But it's not the style that this file uses.
(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?
Depends on: 475053
Attachment #354586 - Attachment is obsolete: true
Attachment #356180 - Attachment is obsolete: true
Whiteboard: [has patch][needs review cbiesinger]
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.
Flags: blocking1.9.1+ → blocking1.9.1-
(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).
Summary: Session restore causes multiple prompts for same password → opening multiple tabs can cause multiple prompts for same password (e.g. when using Session Restore)
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).
(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.
(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.
(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.
(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.
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.
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.
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?
> 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.
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.
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?
(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.
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... :-)
(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... :-)
(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.
No longer depends on: 369963
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.
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.
(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
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
(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.
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.
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?
(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.
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.
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.
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.
@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.
A workaround for the proxy issue is found in bug 339804 comment 87.
(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
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.
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
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.
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.
(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.
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.
Whiteboard: PLEASE READ COMMENT 259 BEFORE COMMENTING
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
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!
Fixed today on m-c (1.9.1a1) in bug 475053.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED
(In reply to comment #264) > Fixed today on m-c (1.9.1a1) in bug 475053. Err, on 1.9._2_a1!
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?
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
No longer blocks: 177175, 356097, 387652
Status: RESOLVED → VERIFIED
Whiteboard: PLEASE READ COMMENT 259 BEFORE COMMENTING → [fixed by bug 475053]
Target Milestone: --- → mozilla1.9.2a1
No longer blocks: 436025
Is bug 499233 a dupe? P.S. if anyone can verify that this is *not* fixed, provide a screenshot. ;)
It's not a dupe, read bug 499233 comment #3
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.)
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)
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.
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.
(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.
* 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.
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.
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.
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.
I confirm. This is NOT FIXED in FF 3.6b4, Windows XP
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)?
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.
(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.
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.
I am still getting multiple prompts for an authentication dialog with FF 3.5.5
(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?
Keywords: verified1.9.2
Whiteboard: [fixed by bug 475053] → [fixed by bug 475053], [STFU about Firefox 3.5.x]
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.
(In reply to comment #289) > 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. Then it's a different bug and I believe there is already a one about that issue. You should find it and comment on that bug or create a new one if you fail to.
This bug is only fixed on the trunk and 1.9.2, so it will be fixed in Firefox 3.6 and later. This bug only covers some of the most frequent causes of multiple-prompts-at-startup. There are other causes that are tracked in other bugs (e.g. bug 499233). Please avoid commenting on those bugs, since the issue is already well understood.
Whiteboard: [fixed by bug 475053], [STFU about Firefox 3.5.x] → [fixed by bug 475053]
just updated from beta 4 to beta 5 and this bug is back again!!! its almost like it hasn't been committed to the trunk properly, issue was fixed in Fx3.6b1, not in b2 or b3, fixed again in b4, now missing from b5, have updated on 2 machines and both have multiple prompts again Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 (.NET CLR 3.5.30729) - Build ID: 20091204143806
This bug is definitely not fixed as of Firefox v3.6 final. It's not uncommon for me to have 2+ password dialogs pop open at the same time. This password dialog box should in all honesty be changed anyway. It's extremely awkward as a Modal dialog and should probably pop up at the top of the browser window in the same way that we are notified to save, not save, or ask us later when entered into a new website.
The behaviour in 1.9.2 is infinitely better than the regression that I experienced at 1.9.1.6. I still got two separate authentication (Basic Auth) for two tabs at the same site, not sure if that is expected or not. This was tested on Fedora 12, x86_64.
Agreed the behavior in Firefox 3.6 w 1.9.2 is better, but the correction also managed to introduce a different authentication bug for me (OS = Win XP Pro) behind an authenticating proxy server: If after starting Firefox the first action that goes through the proxy is an attempt to launch a search using the top search box, Firefox asks for my proxy userid and password, and when that is supplied immediately asks again, and either requires more responses than I am willing to give or never breaks out of that sequence. At least for this particular authentication issue the circumvention is trivial - always go first to an outside web page and supply the proxy authentication for that - then the search box works without needing any further proxy authentication and there is no problem. Perhaps this needs to be reported as a separate bug, but all these authentication problems seem to be different symptoms of a generic problem with authentication handling.
Clarification: The new authentication loop bug issue in comment 295 (first request to proxy server coming from use of the search box) is more subtle than initially described, and not infinite. If you type slow enough, each new character entered in the search box when focus returns to the search box will result in a new proxy authentication window after which focus returns to the search box. But if no additional characters are typed in the search box and an enter response is given, there is one final authentication request, and after that is answered, finally the search is performed. A real pain for a slow typist with a long search string, but if you can type fast enough to complete before the first authentication window pops up, you can avoid all but one redundant authentication request. It is as if the process that returns suggestions for a partial search string is now causing a redundant proxy authentication request.
I think this bug may have sneaked back in, or at least shows its ugly head when upgrading Fx to a new version. I've just applied the 3.6.3plugin1 beta update, noticed it after the last stable update too, and when firefox restarted I got multiple prompts again for each window that was open... restarting the after that is fine again, just the one prompt as expected. can anyone else confirm?
For me this bug has never gone away in any update. I gave up in frustration. Happens on Windows XP, and on Windows 7 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3) for each tab that requires a password at startup and for each plugin, like Foxmarks.
Congratulation, you failed to read comment #280 trough comment #291, it's repeatably mentioned that this bug is not fixed in 3.6 and before, and even in 3.7 only the most common cases are fixed, there are still some other bugs open on the less common causes.
just updated to Fx3.6.7 and received multiple master password prompts on first start-up after applying the update. Restart again with the same tabs open and just the one prompt as expected. something is happening (or not happening) after a new update is applied, that is allowing these multiple prompts to pop-up, it does this for me at home and at work on different machines so not a local install issue. its not a big problem as its only on the initial start-up after an update is applied but i didnt notice it happen for 3.6.4 so I assumed it had been fixed, maybe someone could look into it?
when updating to Fx4.0b9 I received multiple password prompts again, both at home and work. is it still happening to anyone else?
I am having multiple password prompts even when there is no tabs to be opened. My version. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729)
(In reply to comment #303) > I am having multiple password prompts even when there is no tabs to be opened. > > My version. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.16) Gecko/20110319 > Firefox/3.6.16 ( .NET CLR 3.5.30729) Georges, could you please file a new bug, where you CC me, mention your new bug is related to bug 348997, and explain a little more about your Firefox profile? If you see multiple password prompts, but have only one single tab and window, it might be caused by having some addons installed that perform activity on startup. It would be interesting your know your configuration, so we can use it to reproduce your issue. If you think it seems likely that your problem is related to having addons installed, then instead of filing a new bug, you could add your comments to bug 536140. Thanks
I isolated this down to the Toodledo add-on. Someone else reported the same in a review with the add-on. I'm so happy I was able to narrow it down to this plug-in. This was such a PITA.
I know this bug has been opened for quite a while but i'm having a similar issue with the latest version of the browser. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 if restart the browser and have more than one tab open (from previous session) that requires basic auth, i get multiple master password prompts.
I'm using 7.0.1 on Linux, and I always get two simultaneous prompts for the same master password at startup of Firefox. I use Firefox Sync, and my start page required a password. Both passwords are store in the Firefox password manager which is protected by a master password. Typically, the second password prompt appears and takes the focus while I am writing a password into the first one... Somewhat annoying.
One "password required" window is good enough, next one is not needed. It is extremely annoying when next "password required" window opens exactly when I type password into the firs one. Is it going to be fixed? Anyone knows? (FF 11 - Linux).
Well this Bug's status is verified fixed so I don't think any work will be done on this Bug unless the status is different. Try disabling all of your extensions. As I previously stated, for me the problem appeared to be related to the Toodledo extension. I did a binary type search by first disabling all, then only disabling half, then half that, etc. Toodledo did investigate this at length but they were unable to reproduce it. (I was impressed on their follow-up.)
It happened to me too just now. Running v9.0.1 on Windows XP SP3. I have several tab in several windows, many of them requiring a personal certificate to be selected. After start I selected a certificate in the dialog for one site, then entered the master password (not necessarily in this order) and... most tabs hung. Also if I opened new windows and tabs, they would not load. Then I discovered, one of the FF windows has a another master password dialog open. I just clicked OK on it (leaving the password field empty). Is this a regression? Or a new bug? My add-ons are (argh, why is the list not copy/pastable???): - dictionary for slovene - dictionary for german - hungarian dictionary - Firebug - Hermes SoftLab DigSigSDK - Lazarus - Live HTTP headers - Google Wb Toolkit Developer
This bug exists again since lot of versions (I used 31.6.0). Can you resolve this problem? At Thunderbird startup, there is two password windows. Can you look? Thanks in advance. Regards.
(In reply to Neustradamus from comment #311) > This bug exists again since lot of versions (I used 31.6.0). Neustradamus: this particular bug was resolved fixed long ago with bug 475053. maybe you want to be looking at bug 177175?
I confirm this bug STILL EXISTS in Thunderbird 31.7.0
I still have that bug in Firefox 44.0
(In reply to esprit1st from comment #314) > I still have that bug in Firefox 44.0 Confirm that: Maybe it depends on plugins being installed?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: