We have reports of 3.0 not reprompting when bad imap passwords are entered. See https://bugzilla.mozilla.org/show_bug.cgi?id=249240#c89 for a log. We have similar reports for SMTP, but I suspect the fixes will be per-protocol.

I think in this case the server is dropping the connection after the logon failure, so we're not falling through to the code that tries other auth methods, or reprompts for a new password. This will be tricky to fix. if (!clientSucceeded || !GetServerStateParser().LastCommandSuccessful()) { if (!DeathSignalReceived() && clientSucceeded) In this case, LastCommandSuccessful() will be false, because of the NO logon response, but DeathSignalReceived() will probably be true because of the dropped connection. (clientSucceeded always seems to be true, except in the case of gssapi auth failing). If we were to allow ourselves to get into the password reprompting code in the case of a dropped connection, cancel should work, enter new password would forget the old password, and maybe do a retry because of the normal url retry code, and maybe retry would work as well...it's worth trying. But, it's very difficult to test w/o a server that drops the connection on a bad password...perhaps fakeserver could be convinced to optionally do so...

(In reply to comment #1) > the server is dropping the connection after the logon failure, > so we're not falling through to the code that tries other auth methods, > or reprompts for a new password. For POP3, bug 533006(and bug 428611, bug 429069, bug 490140 in dependency tree for that bug) are already opened. Bug 428611 is for worst case. 1. Password prompt, enter wrong password. 2. AUTH PLAIN -> -ERR -> server silently kills connection. 3. Tb tries to fall back to AUTH LOGIN -> wait for response forever. (note: AUTH LOGIN was issued in Bug 428611's case) 4. No pasword is prompted upon next/manual Get Msgs, because old/wrong one which was entered at step 1(or null one) is used for next AUTH PLAIN. So, there is no oppotunity to enter correct password, until restart of Tb in this case.

(In reply to comment #1) > But, it's very difficult to test w/o a server that drops the connection on a bad password... Fortunately, I still use POP3 server/account which was used when I reported Bug 429069, and the POP3 server perhaps still silently kills connection. And, Nelson Bolyard(buh opener of bug 428611) probably still use same server/account. If check with POP3 is required, we still can check POP3 case probably.

David, is this a common case? (or is that hard to tell).

It's hard to say how common it is - I thought one of my servers was doing it at first, but I could not reproduce it. I might need some help from gozer changing my password on the various imap test accounts we have on different servers to see if we can find on that has the issue.

IIRC bug 525238 fixes this.

It seems common for SMTP servers (e.g., hotmail) but I still don't know how common it is for IMAP. That being said, I think I can tweak the imap fakeserver the same way I tweaked the smtp server, though it will cause conflicts with other an other patch I have...bug 525238 has a specific test for cram-md5 auth dropping the connection even on good credentials, but not one for auth plain dropping the connection on a bad password, iirc.

From what I can tell this bug is possibly fixed by bug 525238 but we'd still need to write an explicit case for this bug. Therefore not going to block a 3.0 release on this as the work in bug 525238 is too great to get into the 3.0 releases.