108906 - Threads with only read messages still appear in "Threads with unread" mode

Status: VERIFIED DUPLICATE of bug 64476

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Adam Lock]

I read most newsgroups in threaded view with "View | Messages | Threads with
unread" mode enabled. I regularly see threads in a group that have no new
messages but which remain even if I "Message | Mark | All Read" on the group and
re-enter. The threads won't even go away even when the articles in the thread
have expired.

This happens on all the platforms I've tried it on so it's not a profile thing.

Steps to reproduce:

1. Subscribe to some reasonably busy newsgroup
2. Display the articles in threaded mode
3. Choose "View | Messages | Threads with unread"
4. Read some threads
5. Mark all as read
6. Repeat daily and examine the threads that are listed. Some will contain no
new articles at all.

Comment 1

[Marcin Kasperski]

I can commit this problem: whenever I set the newsgroup to the 'threads with
unread' mode, I see a lot of threads which does not contain any new message. 

In fact, currently (while watching some newsgroup) I have:
- (invalid) info that there are 3 new messages in the 'tree' (problems with this
number I reported as some other bug)
- (correct) empty list of new messages when I set the view to 'View/Messages/Unread'
- (invalid) 12 threads containing 30 messages when I set the view to
'View/Messages/Thread with Unread' (all the messages are correctly displayed as
read).

I have some suspection: seems that I see the threads with messages which I
marked as read using Ctrl-Shift-C (in contrary to reading them indyvidually). So
probably someone forgot to update thread status while handling global marking as
read.

I observe such a behaviour thorough a couple of previous mozilla versions
(currently I use mozilla 0.9.5).

Comment 2

[laurel]

still exists dec14 commercial trunk

Comment 3

[Alfonso Martinez]

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

Comment 4

[scottputterman]

cc'ing bienvenu.  Can this be reproduced in mail?

Comment 5

[Alfonso Martinez]

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

Comment 6

[Ukri Niemimuukko]

I suppose this bug is related to canceled messages as well. 

At least I managed to create one of these zombie threads by canceling one of my
messages. Now the thread keeps on appearing in the "threads with unread" view
even though there are no new messages.

Another group of zombie messages seems to be expired messages, some old threads
give this error message, and clicking the provided link does not help:

Error!
newsgroup server responded:Bad article number

Perhaps the article has expired

Comment 7

[Adam Lock]

Fixing this would be a very visible win for mail/news. Some of the newsgroups in
my client have 10 or so "zombie" threads which will not go away despite every
article being marked as read and having long since expired.

Comment 8

[Mikhail Sogrine]

Is bug 105052 dupe of this one?

Comment 9

[David :Bienvenu]

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

Comment 10

[Mikhail Sogrine]

Another bug that I can reproduce with only messages that are read but are shown
when only unread are shown, i.e. if this bug is encountered. 
I have 1.0rc1 on Win2K.

Reproducible: Always if you have such a message (for me it was the first message
in the thread) and some other messages in this thread. Reporter for this bug
said that it cannot yet be reproduced intentionally but happens sometimes.

Steps:
1. Switch to the news folder with that message -> This thread is always shown
due to this bug with green arrow and subject is underlined (but not bold).
2. Mark this message as unread -> subject becomes bold.
3. Expand thread -> thread triangle points down.
4. Mark all messages read (by key shortcut or by menu item) -> due to this bug
this message is still shown with green arrow, BUT
      Expected result: thread is still expanded and thread triangle still points
down
      Actual result: thread is expanded (visually) BUT thread triangle points RIGHT
5. Click on thread triangle
      Expected result: collapse the thread
      Actual result: second copy of the thread (all messages expect the first
one) appears just after the first message and before the rest of the messages
(you can see where selection goes if expanding and collapsing again) with
correct hierarchy linking.

Steps 2-5 can be repeated to get even more copies of the thread (I got 4 copies
and it doesn't seem to show any changes).

It seems that in this situation, thread is marked as collapsed (see thread
triangle) but list items are not removed and Mozilla continue to show them to
user. -> Question: is it another bug that thread is collapsed by itself after
'mark all read'?

And other comments:
- All messages in all copies are clickable and show correct text below; subjects
pane is scrollable if you have enough messages.
- Going to another folder and returning back resets situation to what was
described in Step 0 (i.e. this bug).
- It does not depend on current View/Messages setting.
- I cannot reproduce it with messages that are read and are not normally shown
when 'Thread with unread'.

Comment 11

[Mikhail Sogrine]

Comment #10:
> - I cannot reproduce it with messages that are read and are not normally shown
when 'Thread with unread'.

Sorry. At last I could reproduce with another message, so it is a separate bug.
I will file it.

Comment 12

[David :Bienvenu]

taking.

Comment 13

[Frank Schönheit]

Mikhail,

regarding your comment #10 and comment #11: Did you file another issue for the
behaviour you described? Since 0.9.9, I encounter this, too (actually slighlty
different: clicking onto the unread (!) root of a thread while the thread is
expanded collpases it without removing the children from the view), but was
unable to reproduce it with a clean profile. In my "real" profile, I stripped it
down to a folder containing only 2 threaded messages, but in a new profile it
does not happen at all.
Very very annoying, and I'd like to see this fixed for 1.0, as it's a major
regression compared to 0.9.8, but as long as I can't exactly reproduce it ... :(

(sorry for misusing this bug here for the question. I tend to not sending
private mail unless explicitly allowed ...)

Comment 14

[Frank Schönheit]

David,

hope you're the right person to address: stumbling through the code, I saw the
nsMsgThread::EnumerateMessages, which creates an object enumerating all
immediate children of a message.

Looking at it, it seems that though not all children of a thread are returned by
the enumerator, at least all are internally _visited_. Which lead me to the idea
of using this to collect some statistics (here: the number of unread children)
about the visited messages, and, once the last message is encountered, correct
the numUnreadChilren of the thread.
This raises the expenses of enumerating a thread, but most of the information
needed is collected by the enumerator anyway, and the expenses can be cut
additionally by collecting the stats in the object enumerating the thread root
only (and not in every enumerator instance).

Yes, this is a workaround at most, as it does not prevent the incorrect cached
numUnreadChildren the thread already stored, it just corrects the number later
on. But for me it works for some time, I didn't see any drawback (except that
threads which contain only the root and no children can't be corrected, as the
enumeration usually takes place while expanding a node), and it really helped me
a lot against all these zombie threads in my groups.

So what all this here finally is about: Would such a "solution" be considered as
a very bad hack? :)

Frank

Comment 15

[David :Bienvenu]

Frank, that would work pretty much as you describe, but I'm working on a
different approach right now. There are two causes of this bug - the simplest
one is that the MarkAllRead command is broken for news: it updates the .newsrc
file, but doesn't update the database at all. I should have a fix for that soon.
The more complicated cause is that the database and .newsrc files can get out of
sync when we crash because they get flushed to disk at different times (because
the .newsrc contains info for all subscribed newsgroups, we can't commit it as
frequently as we do the db for a single newsgroup). So, I'm fixing the newsdb to
also keep track of the current state of the .newsrc line for its newsgroup when
the newsdb is commited. If this doesn't match the .newsrc line the next time the
db is opened, I'll do a synchronization between the two.

Comment 16

[Frank Schönheit]

David,

thanks for the explanations, they alone gave me some valuable insights :)
You're right, fixing the problem at where it is caused is surely better than
working around it. Looking forward to see the fix ....

Comment 17

[David :Bienvenu]

I have to take back the first part of what I said - MarkAllRead generally does
the right thing, usually, as far as the db and the .newsrc are concerned. But, I
discovered, there's one case where it does the wrong thing, and that's when you
do a File | Get Next NN News Messages and then mark all read. It does not mark
the just retrieved previous NN messages read in the .newsrc, because it uses a
lower water mark that's not correct for the range of articles to mark read (it
uses the key of the first hdr downloaded for the newsgroup, and not the "lowest"
key present in the db). So you end up with the articles marked read in the db
but not in the .newsrc.

Comment 18

[John S. Giltner, Jr.]

I have found that if I am replying to a msg and moz crashes that when I restart
moz and go back to that ng, the thread shows that there is 1 unread msg even
though it show the msg unbold (that is read).  No matter what I do the only way
to clear it is to unsubscribe from the ng, and re-subscribe.  I am using NT
Sp6a, moz rc1 2002050908. My last crash was while composing the reply and
attempting to do check spelling.  I hope this helps some.

Comment 19

[David :Bienvenu]

resolving dup.

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

Comment 20

[laurel]

marking verified as a duplicate.