259259 - Messages visually disappearing when closing thread

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Alexander Sascha Fichtner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Thunderbird version 0.8 (20040913)

System: Windows 2000
Thunderbird version: 0.8 (20040913)
Reproduceable: yes

I see some strange behaviour related to thread sorting which I am able to
reproduce for a minimal test case with exactly one thread in one of my folders.
Sorting is set to "Date/Ascending/Threaded" and the thread is unfolded.

This thread should contain 5 mails (i.e. one original and 4 follow-ups). Only
the original and the first follow-up are displayed.

As soon as I manually close this thread the whole thread simply disappears and
won't come back until I switch to another folder and back. Then the original and
first follow-up mails are visible again.

Changing the view to "Unthreaded" will still show only the original and first
follow-up mail, but after switching to another folder and back all the thread's
mails will suddenly be visible in their unthreaded order. Changing back to
"Threaded", all but the original and first follow-up will disappear again.

I also have a testbed with some more threads (chronologically after this "bad"
thread). Whenever collapsing/expanding the first (bad) thread, parts of the
subsequent threads seem to get swallowed and disappear.

Yet after manually moving certain follow-up mails to another folder and back
everything works as expected, all the time.

I have this minimal testbed as a separate folder file. So if need be I can
provide this to anyone who wants to take a look at this problem.

Kind regards,
Sascha

Reproducible: Always
Steps to Reproduce:

Comment 1

[Mike Cowperthwaite]

What are the settings under View|Messages (a.k.a. the MailView dropdown at the 
top of the threadpane) and under View|Threads ?

Comment 2

[Alexander Sascha Fichtner]

Both "View|Messages" and "View|Threads" are set to "All".

Comment 3

[David :Bienvenu]

you can send me the minimal test case and I can look at it. Can you try a recent
trunk build to see if this has already been fixed?

Comment 4

[Alexander Sascha Fichtner]

I just tried the 2004-09-15 trunk build [version 0.6+ (20040915)] and got the
same results. The test case will be on its way in a few minutes. :)

Comment 5

[David :Bienvenu]

that's a good stress test - what's happening is that a parent arrives after its
child, which we do attempt to handle. Up to that point, the child had been the
thread parent. But, what makes this special is that the new parent is a child of
another existing message, so that message really should be promoted to the
thread root (I think it might even be that the third message is a child, and its
parent should be the thread root...) So I think the messages arrived in about as
backwards an order as they could. I'll work on a fix for threading correctly
initially...recovering existing db's from such a corruption is going to be
tricky, however.

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> what's happening is that a parent arrives after
> its child, which we do attempt to handle. 

We do?  See bug 181446.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

the meat of this is in nsMsgThread.cpp, nsMsgThread::AddChild, and
nsMsgThread::ReparentNonReferenceChildrenOf, which was changed to be more
readable and to fix the parent check.

Comment 8

[(not reading, please use [e-mail] instead)]

Comment on attachment 159491 [details] [diff] [review]
proposed fix

should remove commented out lines...

Comment 9

[David :Bienvenu]

Attachment: patch for checkin, removed commented out lines...

this is what was checked in...

Comment 10

[David :Bienvenu]

fixed on trunk.

Comment 11

[Worcester12345]

Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=259185 or
https://bugzilla.mozilla.org/show_bug.cgi?id=259149

Comment 12

[Alexander Sascha Fichtner]

This is only supposed to fix the initial threading problem, and not the existing
threading problem for already "corrupt" databases, right? Any hope on a fix for
the latter? Or do I have to manually fix these db's (which shouldn't be too much
of a problem in my case :) )?

Comment 13

[David :Bienvenu]

you have to remove the .msf files for the folders with corrupt databases.

Comment 14

[Alexander Sascha Fichtner]

Ok, I see. After deleting the .msf file everything seems to work ok for me.
Thanks for fixing this bug! :)