User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3 This applies to the folder panel: When I open the news account, the list of folders appears below. This contains incorrect counts of unread and total messages. Some of the unread counts are negative (clearly in error). Then when I select each newsgroup in turn, the unread/total counts are replaced with the correct values. When I close and re-open the news account, the unread/total counts revert to incorrect values. Reproducible: Always Steps to Reproduce: I ran Ethereal to view the NNTP traffic. When the account is opened, TB makes a GROUP request for each newsgroup. e.g. GROUP Announce.Managing-Director\r\n I noted the results returned from the server (actually Exchange 5.5 in our case). e.g. 211 134 451 610 Announce.Managing-Director group selected\r\n This is repeated for every newsgroup subscribed to on that server. The unread/total counts are updated with incorrect numbers. In the example given, TB lists 17 unread/134 total messages. I then clicked on newsgroups, one at a time. The /same/ NNTP traffic occurs, e.g. GROUP Announce.Managing-Director\r\n 211 134 451 610 Announce.Managing-Director group selected\r\n The unread/total counts update to the correct values, in this example, 0 unread/139 total messages. Actual Results: The unread/total message counts are incorrect initially, but are put right when any newsgroup is selected. Expected Results: The unread/total message counts should be correctly calculated at the outset. This may be related to Bug #217940.

Related to/duplicate of meta bug 71728 (or one of its related bugs) and Core bug 208082?

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This is still a problem with Tb 1.0.6

Yes, this is closely related to meta bug #71728 (or one of its related bugs) and bug #208082 bug #205879

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

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

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

Not sure if this is related. I have one newsgroup where unread counter used to always show the number bigger by ONE than the actual number of unread messages (I think it appeared after I marked one thread as blocked). Hence, It used to say "1" when there were no unread messages. However, today I canceled my own message to that newsgroup a few minutes after posting it (I guess I even left it unread). Now, the unread counter says "2" when it should be "0". I think this might help to narrow the problem down a little - maybe the counter doesn't ignore unread messages that are canceled, but downloaded before cancelling?

(In reply to comment #7) > *** Bug 294754 has been marked as a duplicate of this bug. *** > See bug 294754 comment #3 for a workaround (not a very elegant one, but inelegant is better than nothing).

See dependency tree of meta Bug 71728. DUP of one of Bug 24592, Bug 34406, Bug 41457, Bug 79130, Bug 108650, Bug 202341. Sorry but I don't know which bug is correct one to DUP.

79130, maybe?

Doing some poking around with Wireshark reveals that part of this problem may come from this: GROUP comp.infosystems.www.authoring.stylesheets 211 7634 72504 80183 comp.infosystems.www.authoring.stylesheets XOVER 80180-80183 224 Overview Information Follows 80182\t{ blah, blah } 80183\t{ blah, blah } From telnet {server} 119: GROUP comp.infosystems.www.authoring.stylesheets 211 7635 72504 801084 comp.infosystems.www.authoring.stylesheets ARTICLE 80180 423 No Such Article In Group It seems that initial unread news is lastMessage-lastRead; when some messages are missing in between, that causes the initial unread news message inaccuracies. My understanding of this bug from the summary does not suggest a DUP of 79130: 41457 seems more appropriate, but that seems to indicate the phantom message problem... Too many deps of 71728!

(In reply to comment #12) [...] > My understanding of this bug from the summary does not suggest a DUP of 79130: > 41457 seems more appropriate, but that seems to indicate the phantom message > problem... Too many deps of 71728! > My understanding is that both this and bug 79130 _are_ the phantom message problem, or variations thereon: see in particular bug 294754 summary, bug 294754 comment #3 (the "newsrc edit" workaround), and how it was duped to 79130.

I've done some more poking around because I've been resolving other 71728-dep dupes, and have decided that 24592 is the one most clearly matching this problem (newsgroup counts don't reflect expired messages).