+++ This bug was initially created as a clone of Bug #236510 +++ The problem I reported in bug 236510 is back again, exactly as before. It was considered to have been fixed at one time, but now it's back with a vengeance. I suspect the change to the new password manager has something to do with it. This regression began at about the time that SeaMonkey switched from version 1.5a to version 2.0, but I can't be more specific than that. Please see bug 236510 comment 0 for the original description, and also see Dan Veditz's insightful analysis in bug 236510 comment 4. Bug 236510 was thought to have been fixed by the patch for bug 247417. I don't know what that patch did, or how it fixed that problem, but I hope it will be helpful in solving this problem again. At present, I have 4 email accounts and 4 news accounts. NONE of those accounts specifies "check for new messages at startup", but All 4 email accounts, and one news account are configured to "check for new messages every 10 minutes".

In bug 383229 comment 5, Gavin Sharp explained that the password manager ends up prompting the user for the master password, even though all it really wants to do is to ask if the "software security device" (the crypto token that does the encryption) is logged in, or not; that is, if the master password has been previously entered and is still in effect. I suspect that's what's going on here. The comment in the code that Dan cited in bug 236510 comment 4 clearly says that it is NOT the developer's intent to prompt the user for the mail/news server password, and indeed it does not do so. But if any mail/news server passwords are kept by password manager, it DOES prompt for the master password. I believe that the mail/news developer's intent was to NOT prompt the user in any way, for either server password or for master password. I suspect that the code wants to ask if an encrypted password is available, without prompting the user for the master password, but that the logic for testing to see if an encrypted password exists now prompts for the master password.

If this really is a password manager bug (as I suspect), then I think this bug should be blocking 1.9 rather than (or in addition to) TB3.

Dupe of bug 369963? This is basically another side effect of nsIThreadManager, which I think you've noticed has been the cause of quite a few regressions. :-( AFAIK mailnews is still using the old wallet code, so the new password manager isn't involved.

Justin, in this case, there should be NO master password prompts. The solution is not to reduce the number from greater-than-one to one, but rather to reduce the number of master password prompts to zero. I think the code wants to check to see if it already has the master password, and so can get the server password without user intervention, and do so if possible. But if user intervention is necessary, either to answer a server password prompt or to answer a master password prompt, I believe the intent is to NOT perform the act that would require the user intervention. I think this is more like another manifestation of bug 383229. SM is using the new form field fill-in feature, with the drop-down lists that appear below the form field. I thought that feature was tied to the new password manager, but maybe not?

(In reply to comment #4) > Justin, in this case, there should be NO master password prompts. Sorry, I misunderstood you. > SM is using the new form field fill-in feature, with the drop-down lists > that appear below the form field. I thought that feature was tied to the > new password manager, but maybe not? Nope, separate code.

So what are the STR for this bug?

Months ago, when no relief for this bug was in sight, I changed my server configs to stop remembering mail or news server passwords for any mail or news servers that are configured to fetch new messages either a) on startup or b) every N minutes. I also changed my master password timeout to infinite, so that I would not be prompted for the master password more than once per session, no matter HOW long I let my SM sit idle. As I recall, the STR are something like this: 1) have several mail accounts (at least two) configured a) to remember server passwords, and b) to fetch mail every N minutes, but not at startup. 2) have a news server that is not configured to save server password, but to fetch mail every N minutes. 3) configure SM to ask for a master password if it has not been used for at least M minutes (there is a preference panel for this). Set M to less than N. e.g. M=5, N=10. Then startup the mail/news client, and read news from that news account. wait N minutes, then see one master password dialog appear for each email account configured to remember a password. Then wait N more minutes and watch it happen all over again.

As I review comment 7, I think what I wrote there about > Set M to less than N. is not necessary as a condition for this bug, and may be wrong. That is, perhaps, with M < N, MP password prompts every N minutes is correct behavior. So, I now suggest an alternative: Set M to slightly more than N. I think that will still reproduce this bug, and shouldn't.

I think this is MAJOR. The ability to use a timeout with the Master Password is a major security feature. That is is so broken with mail/news is a big defeat of a major security feature.

is this still an issue with TB? We changed TB to prompt for a master password on startup, if one was set. If this is strictly a SM issue, then we wouldn't block TB on it, so I'm tentatively minusing the blocking flag.

I think it's not? Unless you click cancel in the mp dialog of course, then it will ask you until you just give up and give it the password.

David, the change to TB "to prompt for a master password on startup, if one was set" is only a solution for users whose master password timeout is infinite (never times out), which is the default for TB, but is not the only possible setting. Users who have finite timeouts still see this.

If this is a regression, we should probably want this for TB3 - nominating. (or if it's not, remove the keyword)

(In reply to comment #7) > Then startup the mail/news client, and read news from that news account. > wait N minutes, then see one master password dialog appear for each > email account configured to remember a password. Then wait N more > minutes and watch it happen all over again. We've just fixed the pop3 and smtp parts of this in bug 338549, bug 557622 and bug 557625. Bug 560793 would fix the news part - hence adding dependency.

(In reply to comment #14) > (In reply to comment #7) > > Then startup the mail/news client, and read news from that news account. > > wait N minutes, then see one master password dialog appear for each > > email account configured to remember a password. Then wait N more > > minutes and watch it happen all over again. > > We've just fixed the pop3 and smtp parts of this in bug 338549, bug 557622 and > bug 557625. Bug 560793 would fix the news part - hence adding dependency. This is still true and valid. However, now I revisit this, I don't think we need multiple bugs to cover the remaining (single) news issue. Therefore I'm marking this as a duplicate of bug 560793, as that covers the news issue.