Messages visually disappearing when closing thread



Mail Window Front End
14 years ago
14 years ago


(Reporter: Alexander Sascha Fichtner, Assigned: Bienvenu)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

7.42 KB, patch
Details | Diff | Splinter Review


14 years ago
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,

Reproducible: Always
Steps to Reproduce:

Comment 1

14 years ago
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

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

Comment 3

14 years ago
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?
Ever confirmed: true

Comment 4

14 years ago
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

14 years ago
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.
Assignee: mscott → bienvenu

Comment 6

14 years ago
(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

14 years ago
Created attachment 159491 [details] [diff] [review]
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.


14 years ago
Attachment #159491 - Flags: superreview?(sspitzer)
Comment on attachment 159491 [details] [diff] [review]
proposed fix

should remove commented out lines...
Attachment #159491 - Flags: superreview?(sspitzer) → superreview+

Comment 9

14 years ago
Created attachment 159594 [details] [diff] [review]
patch for checkin, removed commented out lines...

this is what was checked in...
Attachment #159491 - Attachment is obsolete: true

Comment 10

14 years ago
fixed on trunk.
Last Resolved: 14 years ago
Resolution: --- → FIXED


14 years ago
Keywords: fixed-aviary1.0

Comment 12

14 years ago
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

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

Comment 14

14 years ago
Ok, I see. After deleting the .msf file everything seems to work ok for me.
Thanks for fixing this bug! :)
You need to log in before you can comment on or make changes to this bug.