41754 - Threads don't always show up completely.

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[scottputterman]

Open a mail folder and switch to threaded mode.  Every once in a while, a thread 
says it has 3 messages, for example, but only 2 show up.  If you switch to flat 
mode, all 3 are there.

Comment 1

[David :Bienvenu]

I need a reproducible case - I've not seen this.

Comment 2

[David :Bienvenu]

I've found a reproducible case.

1. Find a thread with three messages in it.
2. Select the top level message and expand the thread.
3. Delete the top level message.
4. The thread pane will jump around like crazy. After the dust settles, you'll
see that the thread says it has two messages, but there won't be a twisty next
to it, and the second message in the thread will appear in another place in the
thread pane.
5. Shutting down and starting up again sometimes fixes this, but sometimes it wont.

Comment 3

[David :Bienvenu]

Not sure if this a db problem, a thread view/datasource problem, or a tree
control problem. Will need to investigate. If it's a db problem, it would be
good to fix it before nsbeta2.

Comment 4

[Peter Trudelle]

nsbeta2+

Comment 5

[David :Bienvenu]

OK, I think this is a front end/data source problem. For example, when you 
delete the top message in a thread with three messages, the backend sends 
notifications to the front end saying that the two children messages have been 
removed, and then added, so that the front end can parent the two messages 
correctly. The method nsMsgMessageDataSource::OnItemAddedOrRemovedFromMessage 
ends up getting called, and it has code at the end that does the following:

			//Unread and total message counts will have changed.
			PRUint32 flags;
			//use the changed message to get the flags, but use the 
parent message to change the counts since
			//it hasn't been removed from the thread yet.
			rv = message->GetFlags(&flags);
			if(NS_SUCCEEDED(rv))
			{
				if(!(flags & MSG_FLAG_READ))
					
OnChangeUnreadMessageCount(parentMessage);
			}
			OnChangeTotalMessageCount(parentMessage);

which marks the messages read as far as the tree control/rdf is concerned. I'm 
not sure why this is needed - it seems like the front end should just ask the 
thread for the new counts after the operation is done. Also, this doesn't seem 
to handle putting the counts back when an unread message is added back, which is 
what's going to happen next. I can try adding that to this code, but I'm kinda 
poking around in the dark. Is this code a workaround for some other problem?

Comment 6

[David :Bienvenu]

I have a fix - need a review.

Comment 7

[David :Bienvenu]

fix checked in, but you will need to delete your databases.

Comment 8

[scottputterman]

You are right.  It looks like I tried combining adding/deleting messages and 
ended up only handling the deleting case.  If you didn't fix this then this is 
probably still a bug.  However, the bug that I was filing was happening 
regardless of any front end activity (i.e. I'd shut down and start up and try to 
open a thread and it wasn't completely there.).  It was a case where the count 
would say 3 but there would only be two messages in the thread.  It looks like 
that is what you fixed.

Comment 9

[fenella]

Linux and Mac (2000-06-20-08 M17)
win32 (2000-06-20-09 M17)
This problem has been fixed.