290826 - Unread newsgroup messages are initially calculated incorrectly

Status: RESOLVED DUPLICATE of bug 24592

(Thunderbird :: General, defect)

Description

[Rick Beton]

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.

Comment 1

[zug_treno]

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

Comment 2

[Gervase Markham [:gerv]]

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/

Comment 3

[Rick Beton]

This is still a problem with Tb 1.0.6

Comment 4

[Rick Beton]

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

Comment 5

[Jesse Houwing]

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

Comment 6

[Jesse Houwing]

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

Comment 7

[Jesse Houwing]

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

Comment 8

[Rimas Kudelis [use needinfo to ping]]

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?

Comment 9

[Tony Mechelynck [:tonymec]]

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

Comment 10

[WADA:World Anti-bad-Duping Agency]

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.

Comment 11

[Rimas Kudelis [use needinfo to ping]]

79130, maybe?

Comment 12

[Joshua Cranmer [:jcranmer]]

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!

Comment 13

[Tony Mechelynck [:tonymec]]

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

Comment 14

[Joshua Cranmer [:jcranmer]]

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