User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20061201 Firefox/188.8.131.52 (Ubuntu-feisty) Build Identifier: version 184.108.40.206 (20070326) If one of your mail servers "forgets" your email password, which is a not-uncommon problem on some servers/hosts, then Thunderbird will display the "enter your password" dialog box. That's fine, but the problem is that as long as that dialog is displayed, Thunderbird fails to check your other email accounts for new mail, which makes no sense. So if this dialog comes up say in the middle of the night when you're away from the computer, Thunderbird just sits there, and all your other email accounts fail to check for new mail. This can be problematic in many scenarios, for example any case where you receive time-sensitive emails and you have auto-responders set up for them. The auto-responders won't go out on time because the incoming emails don't come in as they are sent, because Thunderbird isn't checking for new mail. I'm marking this as severity "major", which is perhaps debatable, but it seems to me that failing to check for new mail is a pretty major issue for an email application. Reproducible: Always
Currently this is done step by step, right. David, any chance that we can get the checking be done in a background process while presenting the password dialog in the foreground process? http://lxr.mozilla.org/seamonkey/source/mail/base/content/mailWindowOverlay.js#2386
This sounds like a core mailnews bug.
the backend code needs to wait for a password before proceeding. But I believe there's an existing bug about this issue, and the fix involves using nsIAuthPrompt2, or something like that...this bug happened when all the event loop /thread changes landed on the trunk, iirc.
(In reply to comment #3) > But I believe > there's an existing bug about this issue, I was unable to find it. Does anyone know the bug number?
I'm guessing David may have meant bug 338549, though I don't think that's the case, since this bug is for the branch.
yes, you're right - but there's not much we can do about this. Password prompts basically block the UI thread. The background check for new mail shouldn't ever put up the password prompt, for this very reason, so the middle of the night scenario shouldn't apply. Is that actually happening to you?
> The background check for new mail shouldn't ever put up the > password prompt, for this very reason, so the middle of the > night scenario shouldn't apply. Is that actually happening > to you? If that's a question for me (the bug filer), then yes, that absolutely does happen. Anytime my mail server "forgets" the password for one of my accounts, which unfortunately happens at least once every few months for no good reason, then Thunderbird displays the password prompt, exactly as described in my original post here, and it prevents Thunderbird from checking new mail on any account until I enter the password.
I tried to reproduce this issue with my 220.127.116.11pre and 3.0 trunk build on Mac. I don't see the password dialog by checking for new mail in background. That's with a POP3 account. While using an IMAP account it still retrieves messages after the password was changed. Seems to be a cached connection even I set the count to 0.
we will always cache the inbox connection. If you toggle the offline state, we will close all cached connections.
This bug is actually more widespread than just the "server forgot my password" instance. The problem also occurs whenever Thunderbird displays the "Failed to connect to mail server" error. The bottom line is that Thunderbird's mail-checking is extremely fragile. All it takes to essentially force Thunderbird offline is a temporary network issue, either locally or with the mail server, or anywhere in between -- and such transient network issues are of course quite common. When this happens, Thunderbird shows the "Failed to connect... [OK]" error, and is locked up until the user can get to the PC and click the OK button. This bug bites me about once a week, but it's especially bad when I'm out of town for a weekend or even a whole week. I leave Thunderbird running on my workstation, which has a script that parses the mail file for certain incoming messages and sends auto-replies for them. (Or I might just as well be using Thunderbird's built-in "Reply with Template" filter.) In such a situation where I'm away from the workstation where Thunderbird is running, and this problem occurs on say the first or second day of my trip, then for the duration of the trip, my Thunderbird-based auto-responders are broken, because Thunderbird won't check for new mail until I get back to the PC and click the OK button.
Anthony, Do you see problem using Beta 2? has big fix of Bug 239131 Thunderbird should use the new password manager, which includes numerous improvements http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ (suggest you backup your profile before using beta release)
I can confirm that for at least one case of this bug, it is fixed in v3.0b2. When a mailserver problem causes Thunderbird to display the "Login to mail server <servername> failed [OK]" pop-up, Thunderbird now does continue to download other mail in the background, despite the fact that you cannot interact with Thunderbird at all until you click "OK" on the pop-up. I don't know enough (anything really) about Thunderbird's code to say whether this fixes the bug in all situations (that is, for all possible UI-blocking pop-up messages), but I would guess that the code is similar or the same for all such situations. It would be nice if Thunderbird simply did not use this type of UI-blocking pop-up message at all; but it appears that the issue as I originally reported it here is fixed. Thanks to everyone involved for making this happen.
regarding getting new mail ... WFM per comment 12, and my test with imap using 20090828 trunk build