From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020122 BuildID: 2002012208 If a POP server login attempt fails, Mozilla prompts for a new POP server password. If the user clicks CANCEL, Mozilla nevertheless forgets the old password (saved by the password manager), and refuses to perform another mail fetch attempt until the user re-types the POP server password. Instead, CANCEL should leave the old password untouched, i.e., act as if the cancelled transaction never happened. I run into this frequently because I have my desktop set up to automatically run "mozilla -mail" whenever I log in. This causes a POP server connection to be made immediately, and a login begun; then Mozilla prompts for the Master Password and waits. If I am busy with other work, then I don't type in the Master PW immediately, and the POP server times out. When I eventually type the master PW, a POP timeout error occurs. Then Mozilla prompts for a new POP server password. If I click CANCEL to this request, Mozilla still forgets the old password and refuses to fetch any mail until I re-type the POP password (which means I have to remember it :-) I think two things should be done: 1. Don't connect to the POP server until after fetching the password. This will ensure that the POP login protocol won't time out if the user waits too long to enter the Master Password. This avoids bogus timeout errors altogether. 2. When CANCEL is clicked in any password prompt, do not erase the old password, but leave it unchanged. Reproducible: Always Steps to Reproduce: 1.Configure a POP mail account with a password, and enable saving it in the password manager. Enable encrypted data in the PW manager. Enable fetching POP mail automatically at startup. 2.Exit Mozilla and restart "mozilla -mail" (Master Password prompt appears) 3.Wait long enough for the POP server to time out (10-15 minutes is enough for yahoo). 4.Then enter the master PW. (a POP timeout error is displayed) (A new POP password is prompted for) 5.Click CANCEL to the prompt for a new POP server password. 6.Click Get Msgs to re-attempt the POP fetch. Actual Results: Mozilla again asks for a new POP server password, apparently having erased the old one even though CANCEL was clicked in the previous new-password prompt. Expected Results: Mozilla should not connect to the POP server until after fetching the password, and Mozilla should not forget a password if CANCEL is clicked in a prompt for a new password.

dupe of bug 91656 Please reopen if you disagree ! *** This bug has been marked as a duplicate of 91656 ***

Reopening because bug 91656 doesn't address the issue of Mozilla making the initial POP connection before fetching the password. Currently the POP connection is started before fetching the password, and therefore may provoke the master PW prompt. Mozilla should get the login and password data before starting the POP connection, which will avoid the bogus timeouts completely. This will make the user experience more reasonable.

james_avera@yahoo.com: Mozilla can't get the password because it don't know if the server needs a password ! Mozilla requests the password if the server wants a password. ------------------------------------------------------------------------------- If I send this to my pop3 server: user Matthias.versen@epost.de I get this answer: +OK Password required --------------------------------------------------------------------------------

Why not ask the PW mgr for a saved password in advance? If there is no password saved, then just proceed as is currently done. In any case, the Master PW interaction will be completed before the POP connection. (This assumes the PW manager can be silently queried even if nothing is stored, and nothing bad happens)

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

Changing component to 'General', because bug 170905 saw it in IMAP too. Chaning summary too.

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

Please, check again with a current build if this bug still exists. I think that it was changed some time ago.

As of Mozilla 1.2.1 I am no longer prompted for a password when another user has that POP mailbox open. I receive the message stating that another user has that box open, and when I hit cancel Mozilla does not forget the password.

mass re-assign.

Is it possible to clarify that hitting cancel will not forget the current password? My mail server seems to occasionally fail authentication for no particular reason (overloaded, perhaps). Should it present a dialog like so instead? Feel free to fix the wording! +-------------------------------------------------------+ | Failed to retrieve mail from the server. The error | | was: | | | | Err: Server Temporarily Unavailable | | | | Would you like to retry or enter a new password? | | | | | Retry | | Enter New Password | | Cancel | | +-------------------------------------------------------+ I have *no* idea what clicking cancel will do when prompted after an authentication failure. I usually try entering the password again. It would be nice to mention what was happening.

Just tryed with mozilla 1.8a1 build (w2k and xp pro) and it still erases the password if one hit's cancel to a pop3 authentication...

Exactly the same Bug in Thunderbird version 0.7 (20040616). one of my mailservers denies the login and Thunderbird password-manager simply forgets the password. I think a saved password should always stay saved until explicit instruction to delete. If there is a problem with login you may get an dialog as described by Additional Comment #11 From Matthew Mastracci. Stefan Schäfer

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Thunderbird "losing" passwords to mail accounts has been happening to my wife and me in probably every version of TB we've had, including 2.0.0.9. just now. It seemed to be precipitated when I attempted to open an email for reading while TB was attempting to check my wife's account for new mail. The pop-up box asking for a password opened. I canceled the box and on checking the passwords in tools/options/privacy/passwords, my wife's was no longer there, so had to add it again. We don't use a master password. Detlef Pelz

I strongly support this bug being addressed. Our ISP has a temporary overload problem meaning that its POP3 server throws errors sometimes. For example, if we have two PCs polling for mail, we often get "ERR Mailbox locked, try again later". The impact of this bug is that the user is prompted for a mailbox password, and if the error recurs the only way out is to cancel - upon which Thunderbird 2.0.0.12 forgets the password and can no longer retrieve mail. Real-world (ie less clueful) users tend not to know their mailbox passwords, as a previous bug reporter commented, because this is something "infrastructural". Being prompted to enter it is disturbing and generates support calls. Correct behaviour would be (as shown in previous comment) to have three choices on the error box: Retry / Enter new password / Cancel.

Is this not a dup of bug 123440 ? That bug has more commentary, all of which is useful to the understanding of it, even if it has a larger bug number!

I also find this bug very annoying, possibly the most annoying currently in TB. It would be great to resolve this for all current forks. Surely (my little coding knowledge suggests) it would be fairly trivial to have passwords stored until overwritten by new ones. Similar to bug 123440 as suggested by Glenn Linderman. Which is also annoying. Although the two might be resolvable together by means of notification icons when connection is not available or has a problem instead of pop up windows with password requests.

Nominating wanted-thunderbird3 partly due to the number of dupes and also to keep it on the radar.

Agreed this would be good to fix.

(In reply to comment #11) > Is it possible to clarify that hitting cancel will not forget the current > password? My mail server seems to occasionally fail authentication for no > particular reason (overloaded, perhaps). Should it present a dialog like so > instead? Feel free to fix the wording! > > +-------------------------------------------------------+ > | Failed to retrieve mail from the server. The error | > | was: | > | | > | Err: Server Temporarily Unavailable | > | | > | Would you like to retry or enter a new password? | > | | > | | Retry | | Enter New Password | | Cancel | | > +-------------------------------------------------------+ > > I have *no* idea what clicking cancel will do when prompted after an > authentication failure. I usually try entering the password again. It would be > nice to mention what was happening. > > This looks like it would be the ideal fix to me!

I could almost agree with comment #24, except that asynchronously appearing modal dialog boxes are bad because they block continued operations, and asynchronously appearing dialog boxes that ask for password information could be spoofed by trojans once people are used to answering them. It would be nice if the actual error message was provided; if the password needs to be changed, there should be a facility in Thunderbird/SeaMonkey to allow the user to enter the password as a command, icon, or menu option... a synchronous operation, rather than an asynchronous one. It is true that the "first access" to a mail server is sort of synchronous, but when these dialog boxes appear as part of biff-type operations, they are very susceptible to being spoofed by trojans, as they appear to be asynchronous to the user.

Sure are getting a lot of complaints about this lately... Possibly since gmail imap seems to cause this quite frequently (bug 423354).

What if TB would just silently fail when it can't login to the IMAP server. And then retry. It can set the "lightbulb" (online status) to red or something to show that it's having trouble. And when you put the mouse over it show the error and maybe right clicking on it will give you the option to enter a new pw or something? Anything at all would be preferable the current behavior.

I submitted Bug 423354 > https://bugzilla.mozilla.org/show_bug.cgi?id=423354 I see no solution here. Stephen DeGabiele offered a great suggestion. Thunderbird should never need to ask for passwords if thee are already saved. This really is a serious and chronic problem that I'm sure thousands of users are experiencing. Please make this a priority. The pop up password box pops up for me and all my other users very very often every day. It's truly rediculous and the most annoying thing that happens within any of the many applications we run.

S Davis: Bugzilla is not there to find a solution for you as user. This may be fixed in the Product and you will see that if the status of this bug changes to "fixed" instead of New. If you want to get it fixed faster then attach a patch. >Thunderbird should never need to ask for passwords if thee are already saved. wrong !, example :The password on the server may get changed and the Account will be closed after 3x submitting the wrong password. A banned Account is worse .. If the server answers with an error after sending the login data TB must ask you again because of that. There is AFAIK no standard in the answer and that means that all login errors must trigger this. Create a pop3/Imap log with such a "asks again" case and attach it if the server didn't respond with a error after sending the login informations ! There is an imap log in 423354 comment #8 and this shows that the error is Gmail: 2448[23702f8]: 2365008:imap.gmail.com:NA:CreateNewLineFromSocket: * BYE Temporary System Error Gmail answers with an error directly after login..

Thank you Matthais. I will look out for the error logs. Thunderbird wants to grow just like Firefox so please consider ways to mitigate this problem and/or make it easier for end users to understand and troubleshoot the common root causes of it in a future product release. As it stands today, end users get these "mail server password required" pop ups often if connecting to multiple Imap accounts, but there is no clear indicator of the root cause or resolution so the user gets stuck in an endless frustration loop unable to solve the problem themselves. I appreciate the developer community considering ways to make login error identification and correction faster, easier, and more intuitive for future releases.

(In reply to comment #15) > Thunderbird "losing" passwords to mail accounts has been happening to my wife > and me in probably every version of TB we've had, including 2.0.0.9. just now. > > It seemed to be precipitated when I attempted to open an email for reading > while TB was attempting to check my wife's account for new mail. > > The pop-up box asking for a password opened. I canceled the box and on checking > the passwords in tools/options/privacy/passwords, my wife's was no longer > there, so had to add it again. > > We don't use a master password. > > Detlef Pelz > FWIW, we haven't encountered this bug in a log time now -- perhaps not since 2.0.0.9. We're using TB 2.0.0.14 at present. Our mode of usage hasn't changed, except maybe in that we use TB more frequently since I last wrote, so it looks to us like the bug is fixed. Our thanks to the fabulous TB crew! Detlef Pelz

(In reply to comment #33) > (In reply to comment #15) > > Thunderbird "losing" passwords to mail accounts has been happening to my wife > > and me in probably every version of TB we've had, including 2.0.0.9. just now. > > > > It seemed to be precipitated when I attempted to open an email for reading > > while TB was attempting to check my wife's account for new mail. > > > > The pop-up box asking for a password opened. I canceled the box and on checking > > the passwords in tools/options/privacy/passwords, my wife's was no longer > > there, so had to add it again. > > > > We don't use a master password. > > > > Detlef Pelz > > > > FWIW, we haven't encountered this bug in a log time now -- perhaps not since > 2.0.0.9. We're using TB 2.0.0.14 at present. Our mode of usage hasn't changed, > except maybe in that we use TB more frequently since I last wrote, so it looks > to us like the bug is fixed. > > Our thanks to the fabulous TB crew! > > Detlef Pelz > This bug is certainly *NOT* fixed. You are most likely not experiencing the problem because the mail server you are using is not producing any errors. Use TB with GMail + imap and you will see the problem within a day or two.

Fair enough -- perhaps I should have said, "For *us* it looks like the bug is fixed", since the only variables that have changed since the bug occurred are that we use TB more frequently than we did back then, and there have been several upgrades since then. We use it with two different mail servers -- both POP -- so I guess the problem still exists with other arrangements. Detlef Pelz

It's definitely not fixed as many gmail users will tell you. While it may be difficult to grok the various and different server error messages, it is not impossible. There are less than 10 (major) IMAP servers in use today. Courier, UW, Exchange, Binc, Dovecot and gmail come to mind. I can't understand how the behavior of forgetting the password helps protect the user from being "locked out" of an account, as the user, lacking any information as to why they are being asked for their password, is just going to enter the same "bad" password that they think is correct. The pop-up doesn't mention any information like "Thunderbird has decided to forget your password because it thinks it's 'bad'. "

>There are less than 10 (major) IMAP servers Major doesn't matter, it must work with near all existing and used imap servers. I use for example Hamster as Imap server. I can not understand why you can not understand this, you must think more global not only for your own point of view. A user gets a phone call from the sysadmins or a mail a few days ago which tells him : we got a new Imap server software and all Accounts need new passwords, here is your new password, use it tomorrow morning. User opens Thunderbird at the morninbg and thunderbird send x times the wrong password after opening Thunderbird and account is closed. I agree that there is a UI problem, Thunderbird should tell you why it asks for a new password (The server responded with an error during the login)

Disagree. It does matter, even if there is a fundamental reason why good behavior is impossible -in general-, but it can be made good with specific servers (by parsing their error messages), then it should do that; making T. have bad behavior for everyone if it can be avoided is not desirable. In any case, why can't Thunderbird *ask* the user what to do, offering three choices: - Retry with saved password - Cancel (stop trying) and retain the existing saved password - Change password (leads to new-password dialog) I can't see why it is every desirable to silently forget the old password.

(In reply to comment #37) > A user gets a phone call from the sysadmins or a mail a few days ago which > tells him : we got a new Imap server software and all Accounts need new > passwords, here is your new password, use it tomorrow morning. User opens > Thunderbird at the morninbg and thunderbird send x times the wrong password > after opening Thunderbird and account is closed. That is moronic server behavior, a server should never disable an account because someone sent the wrong password for it a couple times. This is a Denial-of-service vulnerability where an attacker can disable every known account on the system. Although off topic here and some server administrators are morons so this does happen. I agree the solution would be to make Thunderbird come with a dialog if it has two or three failed connection attempts, with the options being retry, abort or change password.

Your description of the "new password created behind my back" issue is correct; that can happen ... however... 1) If Thunderbird gets a wrong password error, it should mark the account for no future access until there is user interaction. However, it shouldn't force the user interaction via a spoofable dialog, and it shouldn't halt processing with a modal dialog. 2) If the user knows that multiple password errors might lock out the account, he should leave the following proposed option checkbox unchecked: Try again after password errors. However, users that will not be locked out would enjoy this setting. The lockout algorithms usually only happen when there are too many attempts in a particular time period, so even if there are lockout possibilities, if the "check for mail" period is such that the time period is not exceeded, the setting could be used by such users, also. The retry should be only at the next biff interval for automatic checking, not immediately, to aid in avoiding lockout. Thunderbird could tell you why it asks for a new password, but isn't the reason always that there was an error during login? So that seems uninformative. If there are other reasons, they are bugs and should be fixed. Thunderbird should never forget the old password. The user shouldn't be forced to type the same one in again in the presence of errors at the server, when it hasn't changed. Even the present, inappropriate, asynchronously appearing modal dialog allows the user to change the password if that is appropriate... but if the problem is due to errors at or communicating with the server, having Thunderbird wipe out the old password and turn off the remember password checkbox is always inappropriate. And if the user has been notified that the password has been changed at the server, and doesn't change it in Thunderbird, and gets locked out, why is that Thunderbird's problem (especially if the proposed "Try again after password errors" checkbox is implemented and checked)? I disagree with the second paragraph of comment #38 and the last paragraph of comment #39 -- Thunderbird should never request a password via an asynchronous dialog -- see my comment #25 for why. I agree with the moronic server behavior idea, but the way passwords are done these days, the server probably can't tell what the password used actually was: if it could tell that the same password is being used repeatedly, it should not call that an attack... that's a user that forget he changed his password, or forgot that it was changed behind his back. I agree it never desirable to forget the old password, until the user says to forget the old password.

I'm sure you guys and gals will agree that over 6 years since initial reporting is quite a while to get a fix. Is there something we are not doing to get it done? I know we need a coder to do the job (I'd do it if I knew how) so how do we go about getting this done? Gmail/Google Mail frequently drops out on IMAP and POP which prompts this error, with the growing popularity of this email provider surely many people must be experiencing this bug. ??? What I'm trying to get at is, how do we up the ante so that Mozilla notice this? Matt

Dependency or duplicate of: bug 423687 and bug 423354 ?

@Matt I agree. 6 years is an unacceptable amount of time for this bug to be in place. My old university has just shifted over to using GMail as their email provider, so any students there using Thunderbird are in for a rough time. I have stopped using Thunderbird because of this issue, as I have 4 GMail accounts that all throw up this message at once. I agree with the idea that the password should not be forgotten - the box should have a retry button if it is impossible to determine if the error was due to an incorrect password or a server problem. that way the majority of us can get back to what we were doing without having to retype our passwords.

Please stop complaining here, this is a bug database and not a Forum. If you want to get it fixed faster you can attach a patch. Please only add a comment if you have new technical (!) informations but not for anything else, thanks

Can someone with the skills to do it please fix this bug? This has been annoying me for years too, and is especially annoying when a mailserver is down. Just look at all the duplicates that have been created through the years by people with the same problem.

I am experiencing this issue with Thunderbird and Gmail IMAP accounts as well. Even after selecting remember password and OK, a failure pops up and it forgets the password. I have also noticed that Thunderbird seems to have login failures to GMAIL without even trying a connection when memory usage by other applications is high.

(In reply to comment #47) Add yourself to the list :) GMail can be flaky at times causing these errors but if there is an issue with Thunderbird and memory then it should be reported as a separate bug. Matt

Retriaging according to new policy for flags. https://wiki.mozilla.org/Thunderbird:Release_Driving (bugs marked wanted- don't indicate we wouldn't accept patches, but that they're not going to be the focus for release drivers)

I'm going to take on these dialogs so we can get this bug moving.

I mid-air collided, which crashed and burned all the settings

Is this dialog showing when the server is disconnected? It appears from the comments that either there is no way to really know the server error or we're just using the same dialog for it. If it's possible to detect login failure vs. server failure we need to separate those kinds of errors. At the same time I don't understand why we would destroy the persons password in any case. Even if the password has changed on the server what does destroying the old password give us? It seems we should at least always keep the old password even if it appears to be failing.

I too am having the same problem as most of the others. I have 2 gmail accounts both of which are connected to TB (2.0.0.16) via IMAP and both of which have their passwords stored in TB and are encrypted using the master password facility. TB frequently prompts me for the password of my primary account during the day, and frequently will do so several times in succession even though I have checked the box to save the password. My secondary account, although not used as much, never requires that I manually enter a password. I've checked the stored passwords for both accounts and they have always been the correct ones. When TB is first started sometimes it will prompt me for the password on my primary account before prompting me for the master password. Other times it will prompt me only for the master password and correctly log on the both email accounts. And, other times I am not prompted for a master password at all. As I mentioned earlier I am never prompted for the password on my secondary email account. This happens frequently enough each day that I will gladly capture any additional information to help resolve the problem, however, I will probably need some technical guidance as to what additional information is required and possibly how and where to get it.

this situation is improved in 3.0 nightly builds - we won't forget passwords on logon failure from the background check for new mail, as opposed to the user checking for new mail on startup, or clicking get new mail. And we won't forget the password if the user has managed to logon once in the session. I'm going to move this off to b2. I hope that the new password manager stuff will allow us more flexibility in our password handling, but I want to wait for that to land before tackling more of this.

On the old password manager the given password was prefilled after the login failed, since the new password manager the password isn't prefilled anymore. So you have to retype it. If you have an free email account from the german webmail provider "web.de" (one of the most frequent provider in germany), than you are not allowed to retrieve your emails more often than every 15 minutes on POP3 accounts. If you are under this limit, than you receive a message and Thunderbird thinks your connection failed. So, you have to retype your password. This is annoying if you had to restart Thundebird e.g. after installing a Add-On. So I also vote for fixing this bug!

so this has regressed? That's not good. Maybe yet an other reason to have our own password dialog.

Could be the fix DavidB did a few years ago was Wallet specific and needs re-evaluation for working with the PWM widget. That fix at least prefilled the textboxes in the popup for the User to verify before activating a re-connect attempt.

Hi everyone, after a little code spelunking I noticed that /content/pippki/password.js (stored inside %TB%/chrome/pippki.jar, where %TB% is the program install dir - open the jar as a ZIP file) has two functions, getPassword() and setP12Password(), that contain exactly the same code. This looks like a bug, and *could* be related to this problem. Unfortunately I am unable to set up a build env to test this... could somebody please check it out? BTW, a quick debugging method might be to add alert("something") to the javascript.

(In reply to comment #59) > Hi everyone, after a little code spelunking I noticed that > /content/pippki/password.js (stored inside %TB%/chrome/pippki.jar, where %TB% > is the program install dir - open the jar as a ZIP file) has two functions, > getPassword() and setP12Password(), that contain exactly the same code. This > looks like a bug, and *could* be related to this problem. Nope. The slightly worse regression problem is in mailnews or toolkit, and the actual bug is in mailnews.

I'll have a look at this, unless Standard8 is actively working on it.

I think what regressed this is this: void nsMsgIncomingServer::GetPasswordWithoutUI(nsACString &aPassword) { aPassword.Truncate(); aPassword happens to have the previously sent password, and this crunches it. Which is a bit goofy because it never actually sets it as an out value; m_password gets set...so I don't really know what the semantics here are meant to be now, but removing that line would probably fix the issue...

This patch is a starter for unregressing putting the password in the password dialog if we do prompt it again. It is unfinished (see the two XXX comments) and doesn't cover the smtp protocol (and maybe news as that does things differently), but its a starter...

I think we might consider this for b2 - it basically gets us back to where we were with b1...

Comment on attachment 362790 [details] [diff] [review] gets us back to b1 behavior - checked in. As long as the unit tests pass, I'm happy to take your word that this fixes the recent regression. Its a simple patch to fix something that was obviously wrong anyway. r/sr=me. We'll leave the bug open, but target it to b3 to try and come up with a full fix.

ok, I've landed the patch, so the regression is fixed - moving off to b3 for remaining issues.

It doesn't look like this is back to beta b1 behavior. It's still forgetting passwords. This is what I'm observing: 1. "Enter your password:" prompt appears and is filled in, but "Use Password Manager to remember this password" is not checked (but it should be). 2. Now since I know there is an error and hitting OK would require me to do so ad infinitum, I click Cancel. Next time I try check email, the "Enter your password:" prompt appears and the password has been FORGOTTEN. 3. If I try again from Step 1 (above) but this time check "Use Password Manager to remember this password" before clicking Cancel, the password is still FORGOTTEN next time "Enter your password:" appears. So "Use Password Manager to remember this password" must be automatically checked for this to work properly.

that was an excellent description of beta 1 behavior, unfortunately.

Here's another example of the silliness of this bug: Shredder starts and attempts to check my Hotmail email. Authentication fails and Shredder reports, "Sending of password did not succeed. Mail server pop3.live.com responded: authentication server unavailable, please try later." Nevertheless, Shredder completely ignores the server response message and immediately asks me to enter my password again! In addition to making "Cancel" not forget password, MailNews Core Shredder desparately needs a way to determine the reason for an authentication failure--rather than treating every authentication failure as a bad password issue.

Per our discussion on irc last night, here's some comments about this bug and where we want to go. Firstly: due to the existing mail protocols, we do not get clear error codes and are not guaranteed specific responses (indeed they may not even be in one language) which is why we can't account for every situation and we have to play it cautiously. UI proposal: If we get to a situation where we think we may need to change the password, offer a dialog as follows: Text: "Thunderbird tried contacting the server 3 times and received the following message: $MSG" Default Button: Retry Other Buttons: Cancel, Enter New Password If the "Enter New Password" button is pressed, then we put up another dialog for changing the password. Suggested Backend Implementation: 1) Look for the existing "ForgetPassword" function calls in mailnews: http://mxr.mozilla.org/comm-central/ident?i=ForgetPassword 2) Instead of calling "ForgetPassword" throw up dialog as described above (maybe function in nsMsgUtils to do it?) I think nsIPrompt::confirmEx can be used to do this - http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/base/public/nsIPrompt.idl#100 3) Adjust the logic around the ForgetPassword calls to handle the responses. 4) For the "Enter New Password" case we can initially just use ForgetPassword as we do now, but I think a better follow-up would be to make it a change password dialog (and use nsILoginManager's modifyLogin function) - but I think this can wait if it means we get 1-3 implemented. I've got a lot on my plate for b3, so if anyone wants to take this off me, please do, ping me on irc if there's questions about the implementation.

Your comment completely hits the nail on its head, IMHO.

Mark Banner, I like the proposal to handle the cases where the user needs to be prompted for a different password. However, you have merely tapped the nail on the head, and it needs a bigger smashing. Please forgive the metaphor mutilation. :) Please make sure that there are no failure conditions where a dialog continually pops up asking for a password. Even in the case where a password is wrong, Thunderbird still has utility and does not need to continually prompt or a password. In your proposal, what happens on the next refresh attempt when a user clicks cancel and the password is retained yet wrong? To be successful here, there needs to be some sort of connection status indicator that can display which accounts are offline in a concise yet thorough manner. It may be difficult to show that one POP connection hasn't been refreshed for 3 hours, 1 IMAP connection is offline, 1 IMAP connection has been disabled intentionally, but one POP and one IMAP are still online. Perhaps we need a single icon/button showing online, partially online, or error conditions can be clicked for more details.

No doubt this has been a major PITA for many users, for a very long time -- thus the huge number of search results and duplicate claims... The auto-change of passwords might seem like a "feature", but nearly 100% of the time, this feature is a major PITA. Seems like a very simple solution: Don't ever auto-change any send or receive passwords. At most, there should be a pop-up notice informing of "server log-in failure -- would you like to alter your password". for many users, for a very long time.....

This is the proposed UI as per comment 71. I've got a patch that I'll post in a minute that is IMAP-only but implements steps 1 - 3, I'll be looking at POP soon. News doesn't seem to use ForgetPassword, and I believe SMTP isn't an issue.

As mentioned, this is the IMAP patch implementing steps 1-3 in comment 71. Still needs some unit tests.

this looks reasonable - just need to make sure that urls with no msg window don't throw up this prompt (e.g., biff).

Comment on attachment 385846 [details] Proposed UI dialog looks good

(In reply to comment #76) > Proposed UI Please make sure that the default is "Retry", and that even if user clicked "Enter new password" there is still a way to back out (i. e. if user changes mind, clicks "Cancel", password will not be forgotten.)

Getting this for b3 would be great, but we wouldn't actually hold b3 for it, I don't think.

Comment on attachment 385846 [details] Proposed UI I think HIGs want button text capitalized.

Great you folks are working on this. For SMTP Every time TB pops up the change password option with the SAVE unticked, even though always ticked, I still ALSO have to reenter password next time I use that account to send. So SMTP is effected unless already fixed elsewhere. Thanks for your work!!

(In reply to comment #78) > this looks reasonable - just need to make sure that urls with no msg window > don't throw up this prompt (e.g., biff). The code actually does this already, but the patch isn't as clear. I have no changed the interface so that we pass nsIMsgWindow rather than the url. (In reply to comment #80) > Please make sure that the default is "Retry", That is what comment 71 says we will have. > and that even if user clicked > "Enter new password" there is still a way to back out (i. e. if user changes > mind, clicks "Cancel", password will not be forgotten.) I'm probably not going to do this in the first version of the patch as that is more complex and I'd like to see how POP3 and SMTP turn out. As I've got this far I'd like to get at least an initial version of the patch in for beta 3 and I can deal with that improvement later either in further patches in this bug, or in a different bug.

I'm still attempting to write a unit test for this, but I'm happy with the patch. I'd like to get this into b3 so we can get some idea of how well it is working. Most of it is fairly obvious I think. I redid the calls in AlertUserEventUsingId which aren't strictly part of this patch, but are a bit of tidy up to avoid going across the imap thread -> ui thread barrier twice. Also enables some tidy of the functions in nsImapProtocol.

Comment on attachment 386024 [details] [diff] [review] IMAP patch v2 >+ // We're not really interested in this, but supply a check value anyway. >+ PRBool checkValue; Just call this dummyValue, saving you a comment ;-) >+ // Error condition >+ message.AssignLiteral("String ID "); >+ message.AppendInt(aMsgId); >+ FEAlert(message, aUrl); I assume we only expect to hit this in development so we don't need to know which server is reporting the alert? >+nsImapIncomingServer::GetFormattedStringFromName(const nsString &aName, ... >+ result.AssignLiteral("Failed to get string named "); s/get/format/ ;-) >+imapLoginFailedRetryButton=Retry No access key? (&Retry iirc)

Comment on attachment 386024 [details] [diff] [review] IMAP patch v2 this seems generally OK - I haven't tried the temporary server failure case, but I verified that I do get reprompted if I change the server password.

(In reply to comment #86) > >+ // Error condition > >+ message.AssignLiteral("String ID "); > >+ message.AppendInt(aMsgId); > >+ FEAlert(message, aUrl); > I assume we only expect to hit this in development so we don't need to know > which server is reporting the alert? I'm not sure whether the context of the error message is visible to users without the above "server" identifier -- please in any case make absolutely sure that users can clearly identify to which account the error message applies. FYI: I have 21 (twenty-one) accounts set up in Thunderbird, a lot of them are hosted on the same server, so a message like "IMAP server myserver.de reported invalid password" doesn't do me any good. It also needs to refer to the account name as given on the "topmost-level" in "Account Settings."

(In reply to comment #86) > >+ // Error condition > >+ message.AssignLiteral("String ID "); > >+ message.AppendInt(aMsgId); > >+ FEAlert(message, aUrl); > I assume we only expect to hit this in development so we don't need to know > which server is reporting the alert? Correct, in theory l10n development can hit this, though with l10n merge that's less likely. It is just what we did before as a fallback so I kept it. > >+imapLoginFailedRetryButton=Retry > No access key? (&Retry iirc) nsIPrompt::confirmEx doesn't give us an access key option. The only way we could do something about this would be to spin our own prompt dialog. Whilst I can see that happening after the next major version of TB/SM, I'm not sure it is what we want to do now.

Updated patch with Neil's comments address except where mentioned in comment 89.

(In reply to comment #89) > nsIPrompt::confirmEx doesn't give us an access key option. Putting a & in front of the letter you want as access key didn't work? (&Retry for _R_etry)

I misread/misunderstood Neil's comment. Patch with accesskeys.

Comment on attachment 386102 [details] [diff] [review] IMAP patch v3a >+imapLoginFailedCancelButton=&Cancel You don't need to do Cancel. It's not expected to have an access key, as the Escape key always works. (Besides, if it was expected to have an access key, then the default Cancel button title would have it anyway.)

Unit test for the IMAP case. In this patch I've also included some changes to alertTestUtils.js including: - fixing returning values from the functions that should be returning values. - fixing getNewAuthPrompter so that it returns an nsIAuthPrompt object. This is in fact the login manager prompter as that is what you'd end up getting running the application anyway. - adding an nsIPromptService implementation. As a result, I've updated test_bug155172.js to use alertTestUtils.js as well. The test should cover all the prompt cases including ensuring we haven't inappropriately forgotten the password. Additionally this means we have an IMAP test using the password manager.

The final version of the IMAP patch addressing Neil's comments.

the test failed with this error - was signons-mailnews1.8-imap.txt not hg added? Directory request for: CurWorkD that we (mailDirService.js) are not handling, leaving it to another handler. TEST-UNEXPECTED-FAIL | C:/mozilla-build/msys/tbirdhq/objdir-tb/mozilla/_tests/xpcshell/test_imap/unit/test_imapPasswordFailure.js | [ru n_test : 87] C:\mozilla-build\msys\tbirdhq\objdir-tb\mozilla\_tests\xpcshell\mailnews\data\signons-mailnews1.8-imap.txt does not exist TEST-UNEXPECTED-FAIL | (xpcshell/head.js) | [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFi le.copyTo]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: C:/mozilla-build/msys/tbirdhq/objdir-tb/mozilla/_ tests/xpcshell/test_imap/unit/test_imapPasswordFailure.js :: run_test :: line 90" data: no] before 139264, after 135168, break 00000000 JS Component Loader: ERROR (null):0

Yep, missed the file, I'm sure I remembered to add it before submitting the patch, but somehow it didn't get onto the bug.

Comment on attachment 386280 [details] [diff] [review] [checked in] IMAP patch v3b Checked in: http://hg.mozilla.org/comm-central/rev/1d71913d2b49

Comment on attachment 386462 [details] [diff] [review] [checked in] IMAP test case v2 Checked in: http://hg.mozilla.org/comm-central/rev/5cf38a1e038e

This patch extends the new retry/cancel/enter new password dialog to the POP protocol as well as IMAP. As a result, there's a little bit of re-arrangement. The actual code for the retry/cancel/password prompt has been moved to nsMsgUtils, with the associated strings moving to messenger.properties. I have also adjusted the POP3 password prompt dialog strings to replace numbers with strings (as l10n like them) and tidy up the strings with appropriate localisation notes (the previous notes were just wrong). Unit test also included.

Comment on attachment 391329 [details] [diff] [review] [checked in] POP patch and unit test one nit - any reason to leave the commented out code in? + // Let OnStopRunningUrl return cleanly before doing anything else. + // async_driver();

(In reply to comment #105) > (From update of attachment 391329 [details] [diff] [review]) > one nit - any reason to leave the commented out code in? > > + // Let OnStopRunningUrl return cleanly before doing anything else. > + // async_driver(); Nope - I was going to use the async items, then realised I didn't need to, just forgot to delete the line.

I am now running the Beta 3 version and using a master password. I have both POP and IMAP accounts set up in it. The password prompt has not been an issue with it, to date. I've had it for 5-6 days now. I have not, therefore, run the fix you provided here. Thank you for your help.

Comment on attachment 391329 [details] [diff] [review] [checked in] POP patch and unit test Checked in with commented out lines removed: http://hg.mozilla.org/comm-central/rev/365823464e88

Last patch for this bug - cover the SMTP case. Notes: - NS_SMTP_CONNECTING_TO_SERVER is an unused string, hence removing. - I swapped the password prompts from ids to names like I did in the other patches (to benefit l10n). - The unit test I had to split into 2 files - the fakeservers and smtp don't quite like doing multiple connections in one test. Seeing as it is in two parts anyway it is quite easy to split.

I ran a TB 3.0 beta 3 on a computer to access gmail via imap - all good Then I changed the password in gmail from the web page. TB didn't ask me to enter a new password, instead kept trying the old password stored in TB until google locked the account - I then had to run the unlockcatchpa app to reset the gmail account. At that point, TB did ask for the password. I will find a computer shortly to test this further.

Re: Comment #110. The problem you describe happens only when you actually change a password... and you should know you need to change it in your email client(s) also, at that point. The problem described by this bug is becomes annoying due to transient network issues, down servers, and the like. If the solution to this bug discovers problems with some servers, systems, or environments in which it is impossible to detect the difference between a password change and a transient error, TB/SeaMonkey should err in handling the condition without prompting the user for a password... because most of the time it _hasn't_ changed. And if it has, the user should know to change it everywhere, not just on the server. OK, that's full circle. Repeat until you understand that the transient error prompting is much more annoying, to many more people, than the occasional user lockout. That said, debugging your situation is appropriate, to verify whether or not there is an error in the logic that discriminates password errors from other errors.

Re: Comment #111. While the full-circle review of the problem is informative, don't use it to justify an inadequate solution. Debugging it to see if there is a better solution is smart -- good call. I would also like to solicit other ideas on the user interface side when an account is not connecting properly. This is regardless of whether gmail (or others) don't differentiate correctly between error conditions. I had previously suggested the use of some connection status indicator when an account is currently in an error state. Alerts can be displayed in multiple places such as on the toolbar, status bar, or the accounts in the All Folders tree. Then, clicking (right clicking?) would bring up a menu or dialog to view and resolve the alerts. Personally, I would like the indicator by the spinning wheel in the upper right corner, but I will leave the specifics to the Thunderbird user interface experts.

(In reply to comment #112) > I had previously suggested the use of some connection status indicator when an > account is currently in an error state. Alerts can be displayed in multiple > places such as on the toolbar, status bar, or the accounts in the All Folders > tree. Then, clicking (right clicking?) would bring up a menu or dialog to view > and resolve the alerts. Personally, I would like the indicator by the spinning > wheel in the upper right corner, but I will leave the specifics to the > Thunderbird user interface experts. This is covered by other bugs and other ideas. Please don't try to expand the scope of this bug further than what it is.

Comment on attachment 391874 [details] [diff] [review] [checked in] SMTP patch and test case >+## LOCALIZATION NOTE(smtpEnterPasswordPrompt): Do not translate the >+## word %1$S. Place the word %1$S where the host name should appear. >+smtpEnterPasswordPrompt=Enter your password for %S: Nit: note doesn't match string (uses %1$S instead of %S).

Comment on attachment 391874 [details] [diff] [review] [checked in] SMTP patch and test case Checked in: http://hg.mozilla.org/comm-central/rev/d58f9a90a0b0

I have raised bug 508256 for changing the "Enter new Password" dialog into more of a "Change Password" dialog as previously suggested in comment 84. This bug is now fixed to the best we can do - any more issues should be filed as separate bugs if they aren't already covered by existing bugs (after having tested with the latest builds).

(In reply to comment #114) > (From update of attachment 391874 [details] [diff] [review]) > >+## LOCALIZATION NOTE(smtpEnterPasswordPrompt): Do not translate the > >+## word %1$S. Place the word %1$S where the host name should appear. > >+smtpEnterPasswordPrompt=Enter your password for %S: > Nit: note doesn't match string (uses %1$S instead of %S). And the winner is: (both mail/ and suite/) $S ;-)

Hmmm... I actually think there is some other aspect to this, as I only get this issue on one installation - from 3 different installations (on 3 different machines)of the same profiles and accounts (using the same servers - not gmail!) and the only one having this issue is the installation on my laptop (VISTA 32bit). the other installations (XP Pro 32bit & VISTA x64) are not having this issue - with the same accounts and servers. If it was a server issue, surely they would all be throwing up this erroroneous behaviour!?!

Forgot to mention, this only started happening on this one machine a week ago - had been working fine up til then,

This is by NO means fixed on my computer. It does not happen on my laptop only on the PC. The PC has just been totally redone. It was happening on the old OS and is Still happening on the New OS with ALL new installs of everything. I am using XP Pro, latest Thunderbird, Firefox 5.5.2 and Gmail. The password prompt still pops up every time I open Thunderbird. It can be canceled of X'd out and the mail will download, BUT it wont stop popping up.

(In reply to comment #121) > This is by NO means fixed on my computer. It does not happen on my laptop only > on the PC. The PC has just been totally redone. It was happening on the old OS > and is Still happening on the New OS with ALL new installs of everything. I am > using XP Pro, latest Thunderbird, Firefox 5.5.2 and Gmail. Which version of Thunderbird are you using? Please include the full version text from about:config. Note that this is NOT fixed in Thunderbird 2 builds - it is fixed in the Thunderbird 3 nightly builds in the sense that it will prompt you for what to do, not for your password.

The version I have the problem with is: version 2.0.0.22 (20090605)

(In reply to comment #123) > The version I have the problem with is: version 2.0.0.22 (20090605) Ok, thanks you either need to wait until Thunderbird 3 is out or use the Thunderbird 3 nightly or beta builds.

Move fixes are needed for V3. 2.0.0.22 is NOT holding most of the settings for assorted things = junk mail is tagged and info is not kept, NOT junk is also tagged as such and also not kept. MOST settings are not stored, they have to redone each time Thunderbird mail is opened. This is past annoying as it seems that there may be other large problems in the settings as well as security and virus problems. JC

Right, I've tried deleting everything and re-installing several times (currently v2.0.0.23) and it hasn't made 1 iota of difference. Yet the same version but x64 on my PC has no issues...

Steve, do you use the old profile?

I deleted the old profile and restored from a previous backup (I use IMAP, so everything is still on the server) I'm thinking I might have to try a complete uninstall and re-input all the accounts manually from scratch. Everything seems to have been OK up until I did the 2.0.0.22 update, so I might try going back to the previous version with a clean install and see what happens - it's just that I haven't had time.

Thunderbird 2.0.0.22 DOES NOT hold any passwords, junk tags, "not a scam", or any similar tag. I seems that what ever part of the software that is supposed to take care of this is missing - it simply does NOTHING at all. Every time I open the mail all tags have to redone each time with the same email addresses. It has become a real pain!!

Is this EVER going to get fixed??? Any new newsletters of other new emails ALSO never hold the correct info = not spam, load images, and all other tags. Thunderbird needs a total redo!!! It is most certainly NOT FIXED !!!!

POP/IMAP server passwords are inappropriately forgotten this is still happening in Version 2.0.0.23 (20090812) if the pop-server refuses connection two times the password is lost (even if one clicks cancel and checks the "remember password"-button) this behavior is really annoying if the server refuses the password often (although it is correct, e.g. web.de) I think an email-client should never forget a password in this way (even if the server sends a bad password message) this bug makes the save password tools nearly useless

(In reply to comment #133) > POP/IMAP server passwords are inappropriately forgotten > this is still happening in Version 2.0.0.23 (20090812) As has already been mentioned this will not be fixed in the Thunderbird 2 series as the changes it requires are too significant. It is fixed in Thunderbird 3 which will hopefully be out within the next month or so. Please do not comment about 2.0.0.x on this bug as there is no viable solution that can be implemented there.

I hope it is fixed in Thunderbird 3 full version. I am currently running 3.0b4 and the master password is now prompting twice on start-up before it accepts it.

In Windows 2000 continues to lose the password. Every time you compose a new message ... when you add a recipient from ldap is to re-enter the password

(In reply to comment #137) > In Windows 2000 continues to lose the password. > Every time you compose a new message ... when you add a recipient from ldap is > to re-enter the password That's probably bug 151447, it certainly isn't this one as this one doesn't reference LDAP.

Situation improved with latest version of Thunderbird -- but NOT resolved. Password window keeps popping up while the emails are downloading. Can be canceled of X out without having to enter password, so its there somewhere. Annoying but not tragic. The window should not still be popping up.

the bug was not fix i still have it in v13

cubicdesign: This report was closed more than two years ago. Please file a new report with exact steps to reproduce. See https://developer.mozilla.org/en/Bug_writing_guidelines

I just changed my password in Cpanel. Then TB asked for a new password and that was it. It doesn't work since then.

cubicdesign: Again: Please file a NEW report and explain it THERE, NOT here. Thanks.