Bug 286628 has become unfixed on the trunk again. To recap: Sometimes a server will report an authentication failure even though the user account name and password are correct. This is usually a transient condition, but it may last for a hour or more. When this happens, the client simply erases the stored account name and password, and expects the user to type them in again from scratch. This was fixed for TB2, but has become unfixed again on the trunk, and is just as irritating as it was 9 months ago. Bug 286628 (and its many duplicates) blocked TB2. This bug should block TB3. The fix for TB2 was to make it so that the client does NOT forget the previously stored name and password. After an authentication failure, fixed TB2 will present a new user name prompt and a new password prompt, but the values are pre-filled with the previously saved values, no matter how many times the server rejected the new values. The fixed TB2 client never automatically discards the saved account name and password. Well, it was fixed for at least 6 months, but it's definitely broken again. Now, the first time there's an authentication failure, the account name and password are immediately forgotten. reproducible: 100%

Can you find a regression range? My cursory looks at cvs blame seem to indicate that nothing has been changed in the immediate vicinity of the authentication code since bienvenu committed bug 286628...

This bug is 100% reproducible ... while the server is rejecting valid authentication credentials. Comcast's NNTP server does this rather often, several times each month, I'd say, sometimes for a few minutes or hours, but occasionally for days at a time. Every time it does, I experience this bug. But at the moment it's not happening (the server is accepting valid credentials) so I won't be able to do anything with the regression range until it starts failing again. I don't know if Mozilla's mail/news team ever sets up test servers for reproducing bugs, but this bug seems like a good reason to do so.

(In reply to comment #2) > I don't know if Mozilla's mail/news team ever sets up test servers for > reproducing bugs, but this bug seems like a good reason to do so. Since I fixed bug 413077, we have a scheme for automated tests (at least for news, and SMTP, although IMAP and POP are in progress). However, it doesn't handle authentication yet, although it should be easy to hack in (there a few other, more pressing matters in the meantime).

If this is a regression, worth blocking TB 3 on. Assigning to Joshua though I expect this may come under the other sort out mailnews auth failures bug.

The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a result, we feel that this bug shouldn't stand in the way of all the other good work getting into the hands of users sooner rather than later. Therefore we are retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242 for more details. The 3.1 release is expected to be a quick release soon after Thunderbird 3.

This bug is a follow-up of 286628, reported at 2005-03-17 and never fixed until now and hurting us every day. To get this finally resolved, I propose the following use-case for error "nntp-authentication failed with credentials exist in password manager": 1. retry authentication 2 times, waiting 15 seconds between retries. 2. If it still fails, raise a panel, explaining user "authentication with news server xyz failed" and ask him, 2.1 ...if he wants thunderbird to retry authentication, (-> 1) 2.2 ...if he wants thunderbird to disable this newsserver until end of seession 2.3 ...if he wants to enter new credentials for this news server. Note 1: Never delete any credentials w/o users explicit confirmation. Note 2: If the above proposal is too complicated to implement, just implement 2.2 Note 3: To make user experience even more comfortable, add a flag in server setting "temporary disabled" HTH, Axel

A good outline of what would be done here would be similar to the password failure dialogs new for IMAP, SMTP, and POP in bug 121647. The primary reasons it hasn't been done is because the internal NNTP authentication abilities are more complex than the other three protocols, and I haven't had time to work on much this semester. Also, as of one of the TB 3 betas, NNTP actually respects the maximum connection limit settings, which should ameliorate this problem.

Moving to blocking-thunderbird3.1rc1 for now. That said, given that NNTP is not a high priority for us these days, I'm very much on the fence about this bug, and we may have to reconsider when the endgame comes around. Joshua, what are the chances looking like that you'll have time to work on this?

Related to MailNews Core bug 435306?

We wouldn't hold for this bug if it were the last bug standing.

Does this also affect mail accounts?

Re comment #8: Given the extensive use of NNTP at news.mozilla.org to provide user support and to communicate between developers, I find it strange that a developer would assert "NNTP is not a high priority for us these days".

I have been plagued with constant re-prompting of username and password. Seems like this issue may be the cause. Very sad to hear that nntp is not a priority. For me it is the only reason for using Thunderbird and I use it all the time for communication with people in the open source community, and to provide support. Hope you can find the time to look into issues with NNTP - it used to work just great.

What makes this worse in TB 8.0 is that the timing of the NNTP requests TB sends out appears to be hosed. When I open the news server folder now, I first get a popup /!\ A News (NNTP) error occurred: Enter password Then I'm prompted to enter the password. Later I may be asked for a user name, or I may just be told /!\ A News (NNTP) error occurred: Request aborted by user So it sounds as if somebody is committing NNTP changes to production versions of TB without enough testing.

What is difference among bug 200606, Bug 314495, bug 437930(this bug)? Is this bug for problems even after fix by Bug 286628 and others are problems before fix by Bug 286628? Do we need to keep three similar bugs separately open? Is this bug (a) for generic "password is somehow forgotten" issue only or for issue of "password is forgotten upon error response to authentication command" only? ("session count limit exceeded" is an example) Or (b) also for issues when or after password is somehow forgotten?

First, both should be closed at this time. The two bugs are on two versions of Thunderbird. The first one was closed. I appended data and information to it. The second bug was requested to reflect on the now old version 7. The routines that transfer information from runtime in order to have them the next run were buggy. I was able to fix it by forcing (a number of times) a new username and new password just for the news group. The tool now contains both usernme with password for my email - and a username and a password on separate lines, not like it was before. But it is finally working. After that, both Firefox and Thunderbird when to REV 8.0 and that rev functioned as it should - taking the parameters for multiple username / passwords and keeping them with itself. The computer has been shut down (not often) since and it still functions. Martin

Comment #19 refers to "both", which implies "two". Which two bugs of the three are meant? Bug #200606, bug #314495, or bug #437930?

Bugs 200606 and 286628 do appear to be exact dups of this one. 314495 is a variant, where the reporter does not use Password Manager but wants to enter the password only once per session. While I sympathize, if this is fixed it will be a workaround for that. The new problem (comment 17 of this bug) is the big one, and I believe it ought to be separate from this bug. It is almost certainly caused by some change to the code between TB 6.0 (where it didn't happen) and 8.0 (where it does). But the two bugs together are a much bigger problem than either would be by itself.

I've reopened bug 702038 which was previously closed as dup of this bug, for analysis of phenomenon/issue reported in comment #17 and comment #19.

Version 8 functioned when it installed. I had tried and tried to fix it - finally it saved my username and password as two arguments - not tied as one. Rev 8 came in and used what was there and worked. What I reported in both bugs was true at the time. It happened on two releases. The password manager was fully functional prior to the version that 'assumed' only one username and one password to be used. This would have been fine for a single ISP, but since ISP's have dumped news groups being threatened by those who download music and movies. EIA was the threat. I don't blame EIA, but their heavy hand and knob boots on kids and single moms is rampant. I had to get another news ISP for news and that worked until these two updates failed until vers 8 passed tests. For regression - in R&E or whatever - I suggest you spend $3 a month and get a minimum account. You can have C++ or another news feed so it won't be a waste. Have at least two usernames (the news server provides you with both username and password) one for email and one for news. that would be ample and cover most of us who have such due to our ISP. Martin Martin

I'm having trouble with news.independent.net now with TB8 but Knode, Claws and Pan are having no difficulty accessing the server. This bug is still happening after more than three years. Any chance of a fix?!

Since TB 8 (and now in TB9) I have this problem too. For the server news.eclipse.org he ask me every time for zhe userdata. somtiemes you can found it inside the saved passwords but not in one entry with username/password, instead 2 entries where are frist username ='the real username' and the second username = 'the password'

Every weekend for the past four weeks eternal-september refused to accept my username and password. Come Monday, reentering then works. It is a real pain in the neck. It would be a great kindness to all of us if you guys would fix this sooner than later.

eternal-september did its thing again on Saturday. Did you fix this bug in 9.0.1?

Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 Not yet fixed. I too had this problem with Eternal September this weekend, with Thunderbird 9.0.1. This won't be fixed until the status of this bug report says "Fixed".

(In reply to David E. Ross from comment #12) > Does this also affect mail accounts? No, as I and others reported, only newsservers (different ones) are involved.

I am a committer on Eclipse JDT project, and I use ThunderBird to respond to user queries on Eclipse newsgroups. However, this bug makes Thunderbird (since version 8.0) fairly annoying to use. I am a bit surprised that such a major usability bug has not been fixed for so long.

(In reply to Deepak Azad from comment #32) > I am a committer on Eclipse JDT project, and I use ThunderBird to respond to > user queries on Eclipse newsgroups. However, this bug makes Thunderbird > (since version 8.0) fairly annoying to use. I am a bit surprised that such a > major usability bug has not been fixed for so long. The Thunderbird 8 regression has been fixed by bug 695309 for Thunderbird 10 that will be released by at the end of January.

(In reply to Mark Banner (:standard8) from comment #33) > The Thunderbird 8 regression has been fixed by bug 695309 for Thunderbird 10 > that will be released by at the end of January. But this bug is still in 'Assigned' state, any reason? Is the problem fixed only partly?

(In reply to Deepak Azad from comment #34) > (In reply to Mark Banner (:standard8) from comment #33) > > The Thunderbird 8 regression has been fixed by bug 695309 for Thunderbird 10 > > that will be released by at the end of January. > But this bug is still in 'Assigned' state, any reason? Is the problem fixed > only partly? To be more specific, the problems starting in TB 8 is a result of a separate bug; bug 695309 essentially reverts the issue back to how frequent it was in TB 7, which is not nonexistent. This bug is assigned because I'm working on a patch to actually fix the original problem (before I realized the password issue was largely a manifestation of bug 695309).

(In reply to Joshua Cranmer [:jcranmer] from comment #35) Thanks for the explanation! I will wait for a fix, for now I have reverted back to version 3.0 which I think used to work for me (before I upgraded to 5.0 and then eventually to 8.0)

Here I was, worried this was going to be an annoyingly hard patch to write and now I find that it takes just fifteen minutes to fix? Of course, bug 560793 and bug 201750 did most of the heavy lifting that this patch needs. :-P The only major concern I have is that this loses both username and password credentials, whereas losing just the password might be better.

Comment on attachment 592548 [details] [diff] [review] Exactly what it says on the tin. Review of attachment 592548 [details] [diff] [review]: ----------------------------------------------------------------- I'd like to see a unit test for this - there should be some of the smtp or pop ones you could base one on - but I'm not going to block landing on that, as I know this is a good improvement on what we have already landed, and we should get testing as soon as we can in this cycle.

In composing this test, I've noticed that NNTP doesn't return an error on auth failure...

Pushed: <http://hg.mozilla.org/comm-central/pushloghtml?changeset=79c37d9ab3e1>