I'm not sure which component this is; it might be on Seamonkey too. TB 3a1-0516, Win2K. Not a problem in 2a1-0518. I have two POP accounts which check mail on startup. I don't save passwords for any accounts, so normally when I start up, I'm prompted for the password for each one. What I'm used to is, whichever server responds first causes the password prompt for that account; that window blocks until the password is entered, after which the second password prompt is shown. What's happening now is the first server responds, the password prompt is shown; then, typically *while* I'm typing the password, the second server's password prompt is put on top. Until I paid enough attention to see what was breaking, I would type along, hit Enter, and see a partially-filled password prompt sitting there -- without focus, at that -- while the second half of the first password was sent to the second server. All very confusing. Steps to reproduce: 1) Configure with two accounts (maybe all account types, but I'm using POP) that both check on startup and do not have passwords saved. 2) Start the program. 3) Observe sequence of password prompts. Actual results: 3) One password prompt is shown, then a second prompt shortly is shown on top of the first prompt. Expected results: 3) First password prompt blocks until dismissed, then second shown. Possibly related to bug 337879. OT: There must be a better mechanism than a series of popups for this situation. There's a similar problem with the "Send Unsent?" prompt, which also doesn't block; user actions (clicks and keystrokes) intended for that dialog can be misdirected to the password prompts that follow, with similarly undesirable results.

(In reply to comment #0) > Possibly related to bug 337879. That bug blames the regression on bug 326273, which seems a feasible cause of this bug as well.

-> me The joys of removing nested event queues! ;-) I suspect it is easy to set this up to occur in the browser as well. I think the right solution is to make password prompting non-modal, and then give the user some more advanced UI that can better handle the accumulation of multiple password prompts.

Actually, I think the best solution is to replace callers of nsIAuthPrompt with a new "nsIAsyncAuthPrompt" that allows the prompt implementor to queue up prompt requests. I'm pretty sure that Christian has spent some time thinking about such an interface.

well, I'd have called it nsIAuthPrompt2, but yeah. But I'm not sure that queuing them up in the impl is necessarily a good idea. Maybe it could queue all the ones that have the same parent, but I think it's fine if different windows prompt for authentication at the same time.

Yeah, queuing per window parent sounds ideal to me too.

Making this bug depend on bug 265780, which is about implementing the smarter 'asynchronous' {auth}prompt.

FWIW: I'm getting this bug, even though I *do* use a master password.

FWIW: I'm getting this bug on one PC but not another (Both have similar configs: WinXP, Tb trunk, multiple mail & newsgroup accounts).

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

One wonders if bug 340222 and bug 340834 are also effects of this.

This appears to be a bug about the fact that multiple password prompts appear all at once instead of one after another. My bug (bug 340358) is about the fact that there are multiple prompts for the master password when there should only be one prompt for the entire Thunderbird session. That seems to me to be a little different than a problem with whether prompts are serial or parallel.

Mentioning the above in case someone didn't read the duplicate bug.

Is there a workaround (like deleting or editing some profile file)? This bug is pretty annoying for those of us who are affected. This bug is "major" but the bug it depends on (bug 265780) is only an "enhancement" (with priority = P2). Could someone please increase the severity of bug 265780, and increase the priority of this bug?

One workaround is to only have one email account that checks email on startup. (Probably not what you wanted to hear. :)

Just in case no one noticed, you don't have to enter any passwords after the first one (in the case of the master password). You can just press the cancel button.

(In reply to comment #14) > One workaround is to only have one email account that checks email on startup. No, I still don't get the Master Password prompt, and I have to enter the one account's password twice. I also still have to enter the other accounts' password (twice each) when I want to see new messages there. I wouldn't call that a workaround (runaround, maybe ;-) ). (In reply to comment #15) > Just in case no one noticed, you don't have to enter any passwords after the > first one (in the case of the master password). You can just press the cancel > button. I don't get the Master Password until *after* all other (double) password dialogs have been entered. Possibly related: Tools / Options / Privacy / Passwords / View Saved Passwords doesn't work (the dialog flashes and then disappears). Since my nearly identical profile at home doesn't show this bug, there must be something I can do to my profile at work (delete passwords file? Which one is it?) that will "fix" this bug... BTW: Why do so many profile files have non-descriptive names? (12345678.s, cert8.db, key3.db, secmod.db, ...) PS. I'm using Thunderbird version 3 alpha 1 (20060719)

(In reply to comment #16) > there must be > something I can do to my profile at work (delete passwords file? Which one is > it?) that will "fix" this bug... Deleting the following files did NOT work: panacea.dat, 12345678.s, cert8.db, key3.db, localstore.rdf

Like the reporter, I don't store my email account passwords in password manager. My experience with this bug is that, at startup, for each POP email account that is configured to check for mail at startup, I get one prompt for the account's email password, and for each IMAP account that is configured to check for mail at startup, I get two simultaneous prompts for the acconut's email password. All these prompts seem to appear more-or-less simultaneously. For IMAP accounts (only), after entering my password into one of the password dialogs (the top one), I can click cancel on the remaining password dialog for that same server, and that account will work fine, because the header fetching has already begun after completing the first dialog.

> No, I still don't get the Master Password prompt FWIW, bug 265780 won't help with that issue, that seems pretty certain.

Resetting pointless block request -- this bug doesn't occur on the 1.8.1 branch. I wanted to mention that, as originally reported, even if I wait for all the password dialogs to be displayed before entering any, I still have to type, then use the mouse to activate the next dialog, then type, then use the mouse, etc. I've discovered no means via the keyboard to activate those dialogs. Since I'm frequently switching between versions, I do that a lot; and furthermore, I now end up waiting when I start TB2 as well until I realize, Oh yeah, this version works right. Does this affect my happiness? Not really. But it's tedious.

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

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

With all the duplicates, and duplicates to duplicates, are you sure this isn't happening on branch? I have had trouble with 2 different users with pop3 and passwords. One on 1.5.0.x branch and the other on that AND THEN a 2.0 nightly branch (tried a nightly to see if issue was fixed, and it was not). Thanks.

> are you sure this isn't happening on branch? Yes. Whatever you see on branch is NOT THIS BUG. If you do see something there and want it fixed, file a separate bug on it and request branch blocking flags.

(In reply to comment #24) > > are you sure this isn't happening on branch? > > Yes. Whatever you see on branch is NOT THIS BUG. If you do see something > there and want it fixed, file a separate bug on it and request branch blocking > flags. > Maybe it was Bugzilla Bug 249240 which was a trunk bug but also fixed on branches. I'll check and see if still an issue.

I assume this bug is the reason that Firefox 2.0 throws multiple password prompts when I access a proxy protected by HTTP digest authentication. This could be particularly bad for a newer user because it appears as though the correct password was incorrect. You type in the correct username and password and when you press OK, there's another password prompt. It has the identical appearance as when you enter the wrong password and are prompted again, except this time it's just the one underneath the first.

Jerry, if you're seeing similar symptoms in Firefox 2, it's a different bug. This bug is fallout from the new thread manager landing which is only on trunk.

This regression bug will be 6 months old this week. Any ETA for a fix?

I also seem to be receiving this issue: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: version 3 alpha 1 (20061126) I have two IMAP accounts and six RSS feeds, all of which require passwords and all of which are set to have their passwords remembered by Thunderbird. I am using a the software security device with a master password and every time I start Thunderbird I receive 8 master password prompts all stacked on top of one another, some of them with RSS login prompts in between (sometimes the RSS login prompts are pre-filled, sometimes they are not; it seems to depend on how fast I am at entering my password into every master password prompt). The pattern goes like this: 1. Master password prompt 2. Master password prompt 3. Master password prompt 4. RSS login prompt (pre-filled) 5. Master password prompt 6. RSS login prompt (pre-filled) 7. Master password prompt 8. RSS login prompt (pre-filled) 9. Master password prompt 10. RSS login prompt (pre-filled) 11. Master password prompt 12. RSS login prompt (pre-filled) 13. Master password prompt 14. RSS login prompt (pre-filled) 15. Master password prompt Even more annoying is that the master password prompts before each of the RSS login prompts (except #3 above for some reason) appear un-focused so you have to click on them before you can type anything. If I attempt to hit cancel to most of the master password prompts, I receive two unlabeled dialog boxes with single-line text input fields, one after the other. However, as long as I enter my master password once, if I cancel all the other master password boxes, I am not asked for my master password again during that session. Reproducible: Always Steps to Reproduce: 1. Set up multiple password-requiring accounts and set them all to save their passwords 2. Enable the software security device with a master password in place 3. Restart Thunderbird Actual Results: Many many password prompts Expected Results: Only one password prompt This did not happen with Thunderbird 1.5.x.x. It only happens with the nightly (3.0a1) builds. P.S. I filed another bug report (361916) but I have marked that as a duplicate of this bug.

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

Another symptom I've seen occasionally is that one of the initial password dialogs is displayed blank -- no text specifying which account, no title text in the title bar. Canceling this results in a second, initialized P/W dialog displayed for (I presume) the same account, as the other accounts' password dialogs are all displayed correctly at first. Which account gets the blank dialog (if any) appears to be a timing issue. I haven't tried entering the password of the presumed account into a blank dialog.

The blank one is a fairly recent regression. I only started seeing it in the last week or so. It is intermittent and the steps to reproduce are unknown.

mcow, re: the blank password box -- I can report that I have seen this issue as well under the same circumstances.

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

Necko now provides the ability to do asynchronous authprompts through nsIAuthPrompt2. Moving this bug to be mailnews only to use the new backend. I will file a separate bug on Firefox.

Actually moving to mailnews.

We'd probably want to look at this patch for ftp - https://bugzilla.mozilla.org/attachment.cgi?id=239459

(In reply to comment #35) > Necko now provides the ability to do asynchronous authprompts through > nsIAuthPrompt2. Moving this bug to be mailnews only to use the new backend. I > will file a separate bug on Firefox. I wish it did but I didn't get around to implementing that yet :/ (Also, the current proposed API I have requires a channel. I don't know if that'd be a problem for mailnews)

Although it is not strictly a duplicate, it appears that the crash while at a master password prompt, reported in bug 368325, is another consequence of this issue.

Am I correct in guessing that the guts of bug 265780 on which this bug depends are actually complete? If so, I'll be happy to try for a patch here (if anyone would like to provide any useful hints, they would be appreciated; I've not been in this code before).

Yeah, the guts of bug 265780 are done as I understand.

Marking blocking per discussion in m.d.a.seamonkey

I'm changing the subject to make it clear that this bug is NOT about "master password" prompts.

Related with bug 409008 (which is for the _browser_ at startup)?

This may get be also related with bug 239131 - maybe it even gets fixed with that

This does happen on SeaMonkey, and not only on Windows. I'm on Linux, and yesterday (20080301) I switched mail clients from Tb2 to the latest Sm 2.0a1pre. After I had defined my four email accounts, I restarted MailNews and got prompted for four passwords in short succession; the four popups opened on top of each other. What's worse, two of these popups had no text at all but only an input box. (I suppose the latter is a different bug, but I don't know which one.) In view of the above I suggest Hardware/OS be changed to All/All.

suggest this may be dog-food-like to alpha users. But I'm not close enough to the issue to comment more.

You may well be right about that. I still encounter this every time I start TB because I don't save passwords, and I have two accounts that prompt at startup; I never know for sure which one will appear first, so unless I happen to see both windows appear before I start typing, I have to wait a few seconds to be sure my password isn't split between two dialogs -- the second grabs focus from the first. This bug also makes bug 413860 worse than it needs to be: it's bad enough the IMAP account is checking for mail contrary to my preference; having to enter the pw and then clear two more prompts for the same account is pretty annoying.

Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.

This should certainly be addressed with 3.0a2! Can we give it a higher priority?

(In reply to comment #53) > This should certainly be addressed with 3.0a2! Can we give it a higher > priority? > From what I understand of the issues I believe that this will need us to migrate to toolkit's password manager before we can look at the changes that need to be done to accommodate this. I think it is possible to get the switch to toolkit's pm done by 3.0a2, but I'm not going to put a timescale on this until that is done. Maybe Justin can correct me, but as I understand it, we effectively need to switch the current nsIAuthPrompt calls to nsIAuthPrompt2 which means we need to use channels for our protocol interfaces?

(In reply to comment #31) > > Another symptom I've seen occasionally is that one of the initial password > dialogs is displayed blank -- no text specifying which account, no title text > in the title bar. > Also confirming that. More than that, sometimes the password prompts are loosing focus, which messes everything up even more. However since the goal is to get only one password prompt per security device (i.e. usually only software security device, but can be also for additional devices such as smart cards), this issue can be neglect for now. The empty prompt happens only at the successive prompts and never for the first one. Additional security devices such as smart cards prompt for the password only at its first use, which is usually when sending the first mail. No further prompting happens for these devices. This in itself might suggest, that the software security device is the trigger for the repeated password prompts. Because when using a different device (smart card / USB token), the device doesn't prompt anymore because of the previous successful authentication. Nelson, since you are a CC for this bug...can you you have a look at the software security module and check why's that and confirm or deny my suggestion?

Eddy, many parts of the browser access the NSS softoken directly, and never access any other modules or tokens. The password manager is among them. So, the reason that you only see this problem with NSS's token is that the problematic software only uses NSS's token.

(In reply to comment #54) > Maybe Justin can correct me, but as I understand it, we effectively need to > switch the current nsIAuthPrompt calls to nsIAuthPrompt2 which means we need to > use channels for our protocol interfaces? That would be nice, but is mostly tangential to the problem here. :) The issue is that in 1.8, triggering any kind of prompt made everything else grind to a halt. That's no longer the case in 1.9. While doing do fixed all kinds of problems, it introduced some other problems (like this). I'm starting work on some Gecko 1.9.1 / 2.0 changes to prompting, but due to the scope it's unlikely any of this will happen in Gecko 1.9. And, in any case, some of this probably needs to be fixed on the Mailnews side. The issue of sequential prompts, in the context of this bug, seems like something that should be fixed by having the caller explicitly wait until the connection (and authentication) to Host A has been completed before moving on to Host B. [OTOH, *I* wouldn't want this... Thunderbird stores all my passwords, and never prompts me. But I want to immediately see new mail on Host B even if Host A is slow or not responding.]

In reply to comment #57 (Just throwing ideas into the air, I'm not sure how feasible this would be) Could it be possible to have the wait, not before authenticating, but before opening a popup? I mean, let everything proceed as now, except that "opening a dialog" would wait if there already is another dialog waiting for keyboard/mouse input?

(In reply to comment #58) > (Just throwing ideas into the air, I'm not sure how feasible this would be) > Could it be possible to have the wait, not before authenticating, but before > opening a popup? I mean, let everything proceed as now, except that "opening a > dialog" would wait if there already is another dialog waiting for > keyboard/mouse input? > Not really funny either if you've got twenty accounts and must enter twenty times the same password every while for the same device...

It is also not good for accessibility if prompts overlap, or if prompts appear in the background. I have one report of an early adopter for Thunderbird 3 on Linux who reports that he gets the prompt for his first account, then the prompt for the second account appears, but is hidden behind the message window, or at least does not gain keyboard focus. He has to alt-tab to a different application, and back, to get the dialog to actually take keyboard focus. I've seen the same happen on Windows too, and it's quite annoying and confusing. Mouse users can simply click inside the dialog, but keyboard users really have to alt-tab away and back into Thunderbird.

Correct. That's a side effect when having about two accounts or more. Confirm this annoyance positively (which might be pursued at a different bug).

Maybe a little bit off topic, but there is another "problem" with password / master password dialogs. Using Firefox and Thunderbird at the same time, sometimes password dialogs from both applications are shown - they are hard to distinguish. Maybe toolkit could be able to make these dialogs different for different apps?

Alexander: good point. Please add your comment to bug 101611 also.

(In reply to comment #64) > Alexander: good point. Please add your comment to bug 101611 also. Done

Alexander: you're right; it's not really on-topic here. If you could file a separate bug, though, that would be great.

This seems likely to either be helped by or actually depend on one of the patches in bug 348997.

it's pretty unlikely those patches will get in in time to help us for b1, right? If that's true, #57 seems pretty on point. Our problem is that I don't think we even know that there is a master security password. It's possible that we could change our check for new mail on startup code to wait for the first url to run. Or perhaps we could pre-flight this whole thing by trying to retrieve a single password from wallet/password manager and waiting for that to finish before trying to run any urls. That might be the easiest thing to try. In theory, that should cause a master password prompt, if there is one; otherwise, it will return a password, or fail w/ an empty password. In any case, once its done, then we can run all our urls.

(In reply to comment #71) > it's pretty unlikely those patches will get in in time to help us for b1, > right? I strongly suspect that issue won't be fixed in 1.9.1. > Our problem is that I don't > think we even know that there is a master security password. You can, see _masterPasswordSet() in browser/components/preferences/security.js

thx for the info, Justin. This patch makes us prompt for the master password, if there is one, at startup, before the three pane ui displays. If the user enters it correctly, then they won't get prompted for it again. If they cancel, or enter it incorrectly, they'll experience this bug. It's a little bit of an odd user experience, but it's way better than getting N master password prompts at startup, where N == the number of accounts checked at startup. If we wanted, we could try to treat the master password, if set, as a profile password, and not allow the user to continue until it's entered correctly. Some people have requested just that, to get a little protection against casual snooping. But this patch doesn't do that. Thoughts?

I'm sure sure, but based on comments 71-73, it sounds to me like David and Justin a presuming that once the master password is entered, it does not need to be entered again for the lifetime of the process. That's not correct in all (or even most) products that use the gecko source base. In general, the user has a configuration choice for the lifetime of the "login" to the "default token". His choices include: ( ) Ask me every time my password is needed ( ) Ask me no more than once every [ N ] minutes ( ) ask me only once for the process. (I think People forget that that flexibility exists because Firefox has chosen to always use "ask once", unless the user uses about:config to change it. But SM gives the user all these choices. Note sure about TB.) It important that changes not take away from users the ability to use other settings than "ask once".

thx for the info, Nelson - TB asks only once for the process. If we were to ask every time the password is needed, then we would be asking one more time than needed with this patch, but I don't think we will be switching to that mode - it's too painful for e-mail.

I myself use the "ask me if I haven't entered the master password for at least 5 minutes" setting. I would HATE it if that broke.

this patch would not affect that, in normal situations.

moving to b2, and attaching the master password prompt patch to bug 437635 instead.

Comment on attachment 348862 [details] [diff] [review] prompt for master password at startup this is now in bug 437635, so it's obsolete for this bug.

As far as I can tell, this no longer depends on bug 265780. Standard8, can you verify that, and if true, remove the dependency? If false, it should either be nominated to block 1.9.1, or we need to figure out some other plan. Thoughts? It also appears that since I posted comment 70 suggesting that the patch in bug 348997 might help us here, that that bug has changed to a different approach, which only solves the problem for HTTP.

(In reply to comment #81) > As far as I can tell, this no longer depends on bug 265780. Standard8, can you > verify that, and if true, remove the dependency? If false, it should either be > nominated to block 1.9.1, or we need to figure out some other plan. Thoughts? Well in theory if it actually implemented asyncPromptAuth then we may be able to use that. However I don't see that happening for 1.9.1 even if we pushed hard for it. I'm also not convinced its the right solution for mailnews at the moment - it requires nsIChannel implementations which ours aren't ready for as far as I can tell. > It also appears that since I posted comment 70 suggesting that the patch in bug > 348997 might help us here, that that bug has changed to a different approach, > which only solves the problem for HTTP. I'm starting to think that whatever route core takes, we need at least one level of "protection" in mailnews. From what I understand looking at various bugs there are two issues: 1) Different accounts will try to prompt for passwords at the same time. 2) IMAP connections which want to open multiple connections to the server will also try to prompt for passwords for each connection. So we need to fix item 2 within mailnews for certain (possibly in a similar way to bug 348997). For item 1 I'm beginning to thing we need to either handle locking for the prompts ourselves and/or implement our own auth prompt system (which we may want to do for "pop tarts").

I am going to work on bug 348997 tomorrow (Friday) and hopefully I will have a first patch during weekend. Problem is that review rounds are extremely slow in that bug.

Standard8: is poptarts a tb3 blocker? Honzab: you might ask biesi out-of-band if he'd be willing to let bz take over the review, since I suspect bz has significantly more Mozilla-related bandwidth than biesi does.

This bug still happening in Thunderbird 3 Beta2 (Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2). If you see the first popup password and start typing, you will type half password in the first passwd popup, and other half in the second password popup. Regards, Renato

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

while Thunderbird 3.0 is based (In reply to comment #88) > Fixed today on m-c (1.9.1a1) in bug 475053. seems only to be fixed in 1.9.2a1+, not 1.9.1 Thunderbird 3.0 is based on. To my opinion, this is not acceptable for this TB release if Lightning is entitled and Popups get multiplicated by used remote Calendars!!! Perhaps we should use this request to force backbranching this fix to 1.9.1 too?!

(In reply to comment #88) > Fixed today on m-c (1.9.1a1) in bug 475053. Unfortunately that bug does not fix this bug. The code there may help us, but it only implements it on http protocols and not mailnews ones.

Marcel: sorry for typo, of course it is on 1.9.2a1. Mark: I probably closed this bug by accident, there were lots of duplicates of bug 475053.

Same troubles with losing focus (Comment #20) in SeaMonkey/2.0b2pre (20090720). BTW it seems to be weakly related to master password issue (multiple same windows vs losing focus) but I don't use it anyway.

I can confirm this bug exists with - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Lightning/1.0pre Thunderbird/3.0b3 I have 2 imap mail accounts which dont ask for password , but 2 Lightning calendars show password prompts with the respective username/password filled in. I have to click OK for how many calendars i have defined.

After 93 comments and over 3 years, it is a bit unclear what this bug actually is anymore. Can someone post a more official "fresh" description? Would it make sense to break this into a few component bugs? Things discussed here include: * Multiple parallel "account password" prompts being displayed on top of each other * Multiple parallel "account password" prompts being displayed on top of each other AND stealing the focus when they pop up (potential security issue here) * Too many "master password" prompts all at the same time (like at startup) * Empty password prompt boxes (no text/labels)

Only the first topic hapening: * Multiple parallel "account password" prompts being displayed on top of each other. When you start Thunderbird (and have multiple accounts), you will see the first popup account passwd prompt. You start type the password and other password prompt will popup and get focus. To avoid this, you need wait all popup account password prompt, and DON'T start type at the first popup prompt.

I'd vote for the second option: > * Multiple parallel "account password" prompts being displayed on top of each > other AND stealing the focus when they pop up (potential security issue here) They not only steal the focus breaking user operation (yes, it IS security issue), they can't give it back to the previous dialog forcing user to switch manually (usually via mouse). Multiple master password prompts and empty password prompt boxes are naturally another bugs.

(In reply to comment #93) > I can confirm this bug exists with - > Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 > Lightning/1.0pre Thunderbird/3.0b3 Just to note, Thunderbird 3 is based on Gecko 1.9.1 where the patch for bug 475053 has not landed and probably will never be.

Initial proposal - whilst we can't easily pick up the core work in bug 475053 this should hopefully do us in the interim period. This patch so far creates an asynchronous prompter service that will store asuth/prompt requests and push them out at the right times. I'm fairly sure the interfaces will need tweaking a bit and none of this has been tested yet, so very much WIP.

I have a patch that lays the foundation for this, currently it just about works for pop. I need to do some more work, so unfortunately it isn't going to make beta 4. I will, however, be getting it into rc1 as soon as I can after the b4 code freeze.

This bug still happening on Thunderbird 3 Beta 4

This patch should fix the POP3 prompts to be serial again. This works for my servers, I believe it would also fix the master password prompt issues for pop-only profiles. There's one issue I haven't resolved yet, that I'm hoping David can help me with - why do both nsPop3Protocol::SendUsername and nsPop3Protocol::SendPassword both want to get the password - is it safe just to prompt the user for the password before SendUsername and then use it as necessary?

This patch works only in POP3? I have 1 pop3 account and 1 imap account... What will happening?

Sorry for opening an old discussion, but is there a reason not to use nsIAuthPrompt2.asyncPromptAuth? The back end has already been implemented in bug 475053. I didn't go through the patch nor this bug deeply but it seems to me that you might duplicate something we already have.

(In reply to comment #103) > This patch works only in POP3? > I have 1 pop3 account and 1 imap account... What will happening? Nothing will change for you until I do the patch for IMAP. (In reply to comment #104) > Sorry for opening an old discussion, but is there a reason not to use > nsIAuthPrompt2.asyncPromptAuth? The back end has already been implemented in > bug 475053. I didn't go through the patch nor this bug deeply but it seems to > me that you might duplicate something we already have. It is always worth checking IMO. In summary: a) that bug isn't on 1.9.1, b) its basic implementation uses channels which mailnews isn't set up for at the moment, c) I'm not convinced if password manager will do the right thing for us there (although it is really hard to tell without actually poking it in depth). What I would say, is that the current step is hopefully a good intermediate step for implementing coping with the async functionality and doing the minimal implementation required for TB 3.

Comment on attachment 404616 [details] [diff] [review] WIP - POP 3 prompts fix this all looks reasonable, though I haven't tried running with it yet. one thing to check is that we're not pegging the cpu while the pop3 password prompt is up - I think the (not so) new threading/event makes that not an issue but we should still look. one nit: 2009: + * Portions created by the Initial Developer are Copyright (C) 1998

This version is slightly better: - It resolves when to get the password by doing it before we do the SendUsername and SendPassword steps. - It avoids the async prompt code when we've already had a connection in the session; we get the stored password from the server if we've not had a password error notification. I've still got the unit tests to update/check - I think there's just some code in there that assumes fully synchronous, which we're not quite now.

I've done some test builds with latest patch. These builds are the very-latest 3.0 code with my current patch. The most noticeable changes will be for folks who have one or more POP accounts and don't store their passwords and don't have a master password. If other folks who regularly use pop accounts could also test that there are no regressions that would give us confidence in landing this. The builds are available here: http://s3.mozillamessaging.com/build/try-server/2009-10-07_07:34-bugzilla@standard8.plus.com-st8-async-pop3/bugzilla@standard8.plus.com-st8-async-pop3-mail-try-linux.tar.bz2 http://s3.mozillamessaging.com/build/try-server/2009-10-07_07:34-bugzilla@standard8.plus.com-st8-async-pop3/bugzilla@standard8.plus.com-st8-async-pop3-mail-try-mac.dmg http://s3.mozillamessaging.com/build/try-server/2009-10-07_07:34-bugzilla@standard8.plus.com-st8-async-pop3/bugzilla@standard8.plus.com-st8-async-pop3-mail-try-win32.installer.exe

Comment on attachment 405043 [details] [diff] [review] POP3 Prompts fix looks reasonable...

(In reply to comment #108) I have 2 POP3 accounts with secure authentication for one of them. I tested the WIN32 version with different settings: no password stored: no prompt for a password, one alert: "Error getting mail password" caused by the secure authentication. POP3 passwords stored: same as above POP3 and master password stored: A prompt for the master password appears. Cancelling or not leads to the same alert mentioned above. Wrong master passwords are not accepted and the prompt returns. In all 3 cases no emails are fetched.

I'm pretty sure Hannes issue isn't with the async prompter part of this patch - more likely how I've hooked into the pop3 implementation. Therefore I'd like to land the async prompter into trunk so that David can work on the IMAP implementation and we can hopefully get one or both landed in reasonable time before TB 3.

I think I reviewed this exact same patch - is it the right patch?

Comment on attachment 407252 [details] [diff] [review] Async Prompter [ext]diff -w would have been helpful. By the way, line 637 introduced trailing whitespace. >+ void onPromptCancelled(); That's going to annoy the Merkins ;-) >+#define NS_MSGASYNCPROMPTER_CONTRACTID \ >+ "@mozilla.org/messenger/msgAsyncPrompter" Nit: ;1 >+function runnablePrompter(asyncPrompter, hashKey) { [Not sure why this needs to be a separate object.] >+ this._asyncPrompter._asyncPromptInProgress = false; Not sure that this is true, erm, correct yet! >+ catch (ex) { >+ Components.utils.reportError("runnablePrompter: " + ex); >+ // Fail the prompt operation to let the consumer fall back >+ // to synchronous promptAuth method if they want to. >+ throw ex; What's the difference between this and not using try/catch? >+ // Find the first prompt key we have in the queue. >+ let hashKey = null; >+ for (hashKey in this._pendingPrompts) >+ break; :-) >+ m_url->GetPrePath(server); This includes the user and port too, right? >+ nsCAutoString passwordResult; >+ >+ // pass the failed password into the password prompt so that >+ // it will be pre-filled, in case it failed because of a >+ // server problem and not because it was wrong. >+ if (!m_lastPasswordSent.IsEmpty()) >+ passwordResult = m_lastPasswordSent; Might as well use nsCAutoString passwordResult(m_lastPasswordSent); >+ NS_NOTREACHED("Did not expect to get POP3 protocol queuing up auth " >+ "connections for same server"); But you expected OnPromptCancelled... You might want to have a private method that updates the next_state which you can call from here and the two other places. >-class nsPop3Protocol : public nsMsgProtocol, public nsIPop3Protocol >+class nsPop3Protocol : public nsMsgProtocol, public nsIPop3Protocol, >+ public nsIMsgAsyncPromptListener Nit: each interface on a separate line please. >+ // Used for asynchronous password prompts to store the password temporarily. >+ nsCString m_passwordResult; Can't you save it on the server? I guess this explains the lack of resilience to prompt queueing of this implementation. What are the circumstances where you would expect to need prompt queueing for the same server?

(In reply to comment #112) > I think I reviewed this exact same patch - is it the right patch? Yes, it is the exact same patch: a diff of the two diffs ;-) 405043 and 407252 shows no differences.

Since RC1, Seamonkey is now always asking for the master password at startup. It used to only ask the first time it is needed. I see this as a serious regression as when I click on a link on another tool (outlook, word, acrobat, etc.) the password prompt is often hidden behind another window and it causes confusion (both of the user and the tool when seamonkey does not open). Could this be related to the workaround for this issue? I have set my startup page to be blank (no form data or password data required). I have also deleted all my pop/imap account passwords (although opening seamonkey browser shouldn't require email passwords). However, neither helped.

(In reply to comment #115) > Since RC1, Seamonkey is now always asking for the master password at startup. > It used to only ask the first time it is needed. I see this as a serious > regression as when I click on a link on another tool (outlook, word, acrobat, > etc.) the password prompt is often hidden behind another window and it causes > confusion (both of the user and the tool when seamonkey does not open). > > Could this be related to the workaround for this issue? That's bug 381269 and you can turn off signon.startup.prompt in about:config.

(In reply to comment #113) > (From update of attachment 407252 [details] [diff] [review]) > [ext]diff -w would have been helpful. > By the way, line 637 introduced trailing whitespace. Sorry, I didn't mean to include the pop part in the patch. > >+function runnablePrompter(asyncPrompter, hashKey) { > [Not sure why this needs to be a separate object.] I found it easier to read.

Just the async prompter this time (so that we can get it in so that bienvenu can do imap whilst I finish pop), comments addressed.

Comment on attachment 408205 [details] [diff] [review] [checked in] Async Prompter v2 >+ __threadManager: null, >+ __log: null, It occurs to me that because anyone wanting to use this component will call queueAsyncAuthPrompt almost immediately that you might as well fetch the main thread (no point caching the manager) and the logger in the constructor. I wonder what happens if the key "happens" to be a predefined Object property ;-)

Comment on attachment 408205 [details] [diff] [review] [checked in] Async Prompter v2 >+ this._pendingPrompts = []; This should be {}, in fact it won't work with [] (custom array enumeration).

Why is the Status: still NEW and not at least "ASSIGNED"?

Comment on attachment 408205 [details] [diff] [review] [checked in] Async Prompter v2 Checked in: http://hg.mozilla.org/comm-central/rev/739135304464 http://hg.mozilla.org/releases/comm-1.9.1/rev/bc4f23225e99

This patch basically works as follows: When the imap thread wants a password, it proxies a call over to the imap server object on the ui thread. If the imap server has cached a password, it returns it, along with a flag saying the imap protocol doesn't have to wait. Hmm, maybe just returning a non-empty password would be sufficient, and I don't the extra out param. In any case, if the ui thread is told it has to wait, it waits for the UI thread to signal it that a password is ready. Meanwhile, the UI thread fires off a request to the async prompt service, with the imap protocol object as the async prompt listener. When the protcol objects gets called back on the ui thread and told it's OK to prompt/get the password from login manager, it calls the imap server object, which tries to get the password from the login manager, and if that fails, it prompts the user. Once it has a password, the protocol object signals a monitor from the ui thread that the imap thread is waiting on. Once the imap thread gets the notification, it uses the password to attempt the login. I've tested that if I have two imap accounts checked on startup, and neither has a password remembered, the password prompts are serialized. I haven't tested that the master password prompt would only come up once, though I think that just falls out. I haven't tested the various failure cases - e.g., bad passwords, prev password fill-in, and user canceling the password prompt. This patch is a bit scary, though I guess it could be a lot worse. I'll run with it a bit, and maybe tweak it a bit, and then generate try server builds. One thing - if we get both pop3 and imap using the new prompting service, we can remove the hack in the front end that preemptively causes a master password prompt, because some users complain that we're putting up the master password prompt in cases where we didn't used to.

This cleans up the patch a bit, but there's an issue that arose during testing that I'd appreciate some feedback on : Imagine two password requests get queued up, and the first runs. If the first password entered fails, we put up alerts, and ask the user if the want to re-enter the password, and if the user says yes, we end up letting the second requested password prompt come up, which would be a bit confusing for the user.

The Thunderbird drivers have discussed this bug in the context of Thunderbird 3 yesterday and we have come to the conclusion that the risk of the changes need to resolve this bug versus what it will actually fix and the time to get this stable in Thunderbird 3, are too great for us to include the fixes for Thunderbird 3. We are currently planning a much shorter (currently 4 month) development cycle for the next version after Thunderbird 3 and will be fixing this bug there where we also have potential to use the better support in gecko. Adjusting blocking flags accordingly.

Your "drivers" need to take a step back and think about product quality/user perception vs adherence to a predefined schedule. With the various usability problems that the current builds of Thunderbird have, coupled with how slow it is compared to TB2, I think TB3's reception is going to be quite a disappointment once the 'cool' factor wears off from the new (and very good) features that TB3 comes with. I'm certainly wishing for quite some time now that there was a half way decent alternative to TB3 that I could switch to until these problems are fixed... And I keep hoping that the progress to a Final TB3 would fix at /least/ these major usability problems. I mean really... you are going to allow a major usability problem at startup of TB3 to land in a final build? You know how ridiculous this is going to look to the wider audience? Push the all-mighty-release-date back already... I'm not saying any of that because I think I deserve to have a fully featured/functional email client from you all (though I'd appreciate it!), but rather I think we all know that TB3 has a great feature set and the potential to be a widely adopted email client. However, you'll kill peoples perception of TB3 with stupid problems like this and it certainly won't help adoption. I imagine just about every review is going to contain something along the lines of: "great potential, but wait for 3.1 to see if it's worth keeping / upgrading to"

Current feedback suggests that most users are finding Tb3 to be significantly faster than Tb2 in a bunch of ways. If you are aware of cases where it's slower, please file bugs. Thanks!

SeaMonkey 2.0 asks for the master password on every browser start if it is set, even if there is no mail account (e.g. by "change master password" on an empty new profile). I've lost quite a lot of time searching bugzilla for this annoying behaviour and the workaround by switching signon.startup.prompt to false. IMHO this is unacceptable for a final release. At least there should be a prominent note about it. Now its rather impossible to understand the hint in the release notes: "MailNews account password prompts are no longer serial at startup (Bug 338549) Workaround: If a Master Password is set and you saved your login credentials, only one prompt will appear at startup. You can disable this new behavior by setting signon.startup.prompt to false in about:config." I hope this will be fixed completely soon. In the meantime, the default should be not to prompt on startup.

Bug 530010 packages this file, TB part.

(In reply to comment #128) > SeaMonkey 2.0 asks for the master password on every browser start if it is set, > even if there is no mail account (e.g. by "change master password" on an empty > new profile). > > I've lost quite a lot of time searching bugzilla for this annoying behaviour > and the workaround by switching signon.startup.prompt to false. > > IMHO this is unacceptable for a final release. > This action is the same in Thunderbird 3.0 A password bar with the text "Please enter the master password for the Software Security Device." pops up upon start or any attempt to access individual mail accounts. I also agree it is a bug that should not have been let into the final release. > At least there should be a prominent note about it. > Now its rather impossible to understand the hint in the release notes: > "MailNews account password prompts are no longer serial at startup (Bug 338549) > Workaround: If a Master Password is set and you saved your login credentials, > only one prompt will appear at startup. You can disable this new behavior by > setting signon.startup.prompt to false in about:config." > > I hope this will be fixed completely soon. In the meantime, the default should > be not to prompt on startup.

Hit enter by mistake and missed some of my reply. To remove the master password for ThunderBird in XP, I had to head to C:\Documents and Settings\[username]\Application Data\Thunderbird\Profiles\ and dig around in my profile folders for key3.db and delete that file. That also deletes other stored passwords for ThunderBird, but at least it removes the master password and it's request.

Since this is a regression from Thunderbird 2, I think it probably does actually block 3.1. Targetting at beta1 since it seems likely to require some baking time. Of course, this still has to be balanced against all the other work on Standard8's plate.

I'm using: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.1.8) Gecko/20100216 Lightning/1.0b1 Thunderbird/3.0.2 And *sometimes*, when I start Thunberbird, it show me a repeatable password prompt. Check image attached

This is David's imap fix v2 fixed for bitrot.

In the bugs this one depends on we've fixed the IMAP and POP3 protocols so that the password prompts will now appear in serial fashion. These fixes will be in Thunderbird 3.1 beta 2 when it is released in a couple of weeks. SMTP (bug 560792) and NNTP (bug 560793) are still to be resolved however the Thunderbird drivers consider that it their prompting on startup would be a rare case for the majority of users and hence wouldn't block 3.1. The bugs I've referenced will track fixing of those protocols, so this one is being marked fixed as we've dealt with the vast majority of cases (and otherwise this bug would effectively become a duplicate and not very useful). If there are any follow-up issues from these changes, please file them as separate bugs.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.14) Gecko/20100930 SeaMonkey/2.0.9 This is still a problem. The default setting of signon.startup.prompt still causes a request for my master password when I launch SeaMonkey. Note that I launch only for the browser. I leave Mail-News closed.

David, see comment 140 last paragraph and do what Mark asked. /be