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:
What are the settings under View|Messages (a.k.a. the MailView dropdown at the top of the threadpane) and under View|Threads ?
Both "View|Messages" and "View|Threads" are set to "All".
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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. :)
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
(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.
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.
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+
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
fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Is this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=259185 or https://bugzilla.mozilla.org/show_bug.cgi?id=259149
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 :) )?
you have to remove the .msf files for the folders with corrupt databases.
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.