121647 - POP/IMAP server passwords are inappropriately forgotten

Status: RESOLVED FIXED

(MailNews Core :: Networking, defect, P2)

Description

[Jim Avera]

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.

Comment 1

[Matthias Versen [:Matti]]

dupe of bug 91656

Please reopen if you disagree !

*** This bug has been marked as a duplicate of 91656 ***

Comment 2

[Jim Avera]

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.

Comment 3

[Matthias Versen [:Matti]]

[e-mail]: 
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 [e-mail]
I get this answer:
+OK Password required
--------------------------------------------------------------------------------

Comment 4

[Jim Avera]

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)

Comment 5

[Jo Hermans]

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

Comment 6

[Jo Hermans]

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

Comment 7

[Felix Miata]

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

Comment 8

[Alfonso Martinez]

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

Comment 9

[david fuller]

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.

Comment 10

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 11

[Matthew Mastracci]

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.

Comment 12

[Luis Miguel Lagoa Baptista Ferro]

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...

Comment 13

[Stefan Schäfer]

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

Comment 14

[(not reading, please use [e-mail] instead)]

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

Comment 15

[Detlef Pelz]

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

Comment 16

[Stephen]

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.

Comment 17

[Glenn Linderman]

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!

Comment 19

[Matt]

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.

Comment 22

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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

Comment 23

[Magnus Melin [:mkmelin]]

Agreed this would be good to fix.

Comment 24

[Stephen DeGabriele]

(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!

Comment 25

[Glenn Linderman]

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.

Comment 27

[Magnus Melin [:mkmelin]]

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

Comment 28

[Stephen DeGabriele]

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.

Comment 29

[S Davis]

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.

Comment 31

[Matthias Versen [:Matti]]

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..

Comment 32

[S Davis]

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. 

Comment 33

[Detlef Pelz]

(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

Comment 34

[Stephen DeGabriele]

(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.

Comment 35

[Detlef Pelz]

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

Comment 36

[Gerry Lawrence]

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'. "

Comment 37

[Matthias Versen [:Matti]]

>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)

Comment 38

[Jim Avera]

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.

Comment 39

[Baldur Gislason]

(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.

Comment 40

[Glenn Linderman]

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.

Comment 41

[Matt]

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

Comment 42

[Peter Lairo]

Dependency or duplicate of: bug 423687 and bug 423354 ?

Comment 44

[Jamie Penney]

@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.

Comment 45

[Matthias Versen [:Matti]]

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

Comment 46

[TG]

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.

Comment 47

[Justin Bell]

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.

Comment 48

[Matt]

(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

Comment 49

[Mark Banner (:standard8)]

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)

Comment 50

[Bryan Clark (DevTools PM) [:clarkbw]]

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

Comment 51

[Bryan Clark (DevTools PM) [:clarkbw]]

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

Comment 52

[Bryan Clark (DevTools PM) [:clarkbw]]

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.

Comment 53

[Cheech]

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.

Comment 54

[David :Bienvenu]

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.

Comment 56

[Nomis101]

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!

Comment 57

[David :Bienvenu]

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

Comment 58

[Ronald Killmer]

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.

Comment 59

[bitzinius]

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.

Comment 60

[Mark Banner (:standard8)]

(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.

Comment 62

[David :Bienvenu]

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

Comment 63

[David :Bienvenu]

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...

Comment 64

[Mark Banner (:standard8)]

Attachment: Part 1 - Unregress including prompt in password dialog (WIP)

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...

Comment 65

[David :Bienvenu]

Attachment: gets us back to b1 behavior - checked in.

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

Comment 66

[Mark Banner (:standard8)]

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.

Comment 67

[David :Bienvenu]

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

Comment 68

[IU]

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.

Comment 69

[David :Bienvenu]

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

Comment 70

[IU]

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.

Comment 71

[Mark Banner (:standard8)]

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.

Comment 72

[Ralf G. R. Bergs]

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

Comment 73

[Duane Bronson]

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.

Comment 75

[dbkh999]

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.....

Comment 76

[Mark Banner (:standard8)]

Attachment: Proposed UI

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.

Comment 77

[Mark Banner (:standard8)]

Attachment: IMAP patch

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

Comment 78

[David :Bienvenu]

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

Comment 79

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 385846 [details]
Proposed UI

dialog looks good

Comment 80

[Ralf G. R. Bergs]

(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.)

Comment 81

[Dan Mosedale (:dmosedale, :dmose)]

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

Comment 82

[Magnus Melin [:mkmelin]]

Comment on attachment 385846 [details]
Proposed UI

I think HIGs want button text capitalized.

Comment 83

[dbkh999]

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!!

Comment 84

[Mark Banner (:standard8)]

(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.

Comment 85

[Mark Banner (:standard8)]

Attachment: IMAP patch v2

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 86

[[e-mail]]

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 87

[David :Bienvenu]

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.

Comment 88

[Ralf G. R. Bergs]

(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."

Comment 89

[Mark Banner (:standard8)]

(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.

Comment 90

[Mark Banner (:standard8)]

Attachment: IMAP patch v3

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

Comment 91

[Magnus Melin [:mkmelin]]

(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)

Comment 92

[Mark Banner (:standard8)]

Attachment: IMAP patch v3a

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

Comment 93

[[e-mail]]

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.)

Comment 94

[Mark Banner (:standard8)]

Attachment: IMAP test case

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.

Comment 95

[Mark Banner (:standard8)]

Attachment: [checked in] IMAP patch v3b

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

Comment 96

[David :Bienvenu]

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

Comment 97

[Mark Banner (:standard8)]

Attachment: [checked in] IMAP test case v2

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 98

[Mark Banner (:standard8)]

Comment on attachment 386280 [details] [diff] [review]
[checked in] IMAP patch v3b

Checked in:
http://hg.mozilla.org/comm-central/rev/1d71913d2b49

Comment 99

[Mark Banner (:standard8)]

Comment on attachment 386462 [details] [diff] [review]
[checked in] IMAP test case v2

Checked in: http://hg.mozilla.org/comm-central/rev/5cf38a1e038e

Comment 104

[Mark Banner (:standard8)]

Attachment: [checked in] POP patch and unit test

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 105

[David :Bienvenu]

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();

Comment 106

[Mark Banner (:standard8)]

(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.

Comment 107

[u289014]

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 108

[Mark Banner (:standard8)]

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

Comment 109

[Mark Banner (:standard8)]

Attachment: [checked in] SMTP patch and test case

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.

Comment 110

[Robert Cox]

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.

Comment 111

[Glenn Linderman]

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.

Comment 112

[Duane Bronson]

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.

Comment 113

[Mark Banner (:standard8)]

(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 114

[[e-mail]]

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 115

[Mark Banner (:standard8)]

Comment on attachment 391874 [details] [diff] [review]
[checked in] SMTP patch and test case

Checked in: http://hg.mozilla.org/comm-central/rev/d58f9a90a0b0

Comment 116

[Mark Banner (:standard8)]

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).

Comment 118

[Jens Hatlak (:InvisibleSmiley)]

(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 ;-)

Comment 119

[Steve Renouf]

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!?!

Comment 120

[Steve Renouf]

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

Comment 121

[joyce chapman]

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.

Comment 122

[Mark Banner (:standard8)]

(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.

Comment 123

[Steve Renouf]

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

Comment 124

[Mark Banner (:standard8)]

(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.

Comment 125

[joyce chapman]

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

Comment 126

[Steve Renouf]

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...

Comment 127

[Christian Ertl]

Steve, do you use the old profile?

Comment 128

[Steve Renouf]

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.

Comment 129

[joyce chapman]

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!!

Comment 131

[joyce chapman]

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 !!!!

Comment 133

[peter.schauss]

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

Comment 134

[Mark Banner (:standard8)]

(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.

Comment 135

[u289014]

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.

Comment 137

[Ruyman Hernandez]

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

Comment 138

[Mark Banner (:standard8)]

(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.

Comment 139

[joyce chapman]

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.

Comment 141

[cubicdesign]

the bug was not fix
i still have it in v13

Comment 142

[Andre Klapper]

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

Comment 143

[cubicdesign]

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

Comment 144

[Andre Klapper]

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