Often, but not always, if I'm in Thread view and delete messages in the thread, I get the following behavior: Before: - Thread posting 1 -- Thread posting 2 --- Thread posting 3 Then I delete posting 1 and I get: After: - Thread posting 2 -- Thread posting 2 --- Thread posting 3 With the second entry being a ghost entry: clicking on the message doesn't show any content.

System: Windows 2000 Thunderbird version: 0.4 Reproduceable: Unfortunately, no Related bugs: 216310 and 231846 (maybe; they sound similar) User: Anthony R. Thompson, athomps@netspace.org Summary: First-time (after install) expanding & contracting a thread caused one message per expansion/contraction to seemingly disappear from the mailbox; switching to another mailbox and coming back "restored" the messages and the bug was not reproduceable. Detail: I experienced a similar bug to this one. Fresh install of Thunderbird 0.4 today, the first time I clicked the "Click to display message threads" icon, it seemed to work fine (the one thread in the mailbox was displayed properly, expanded). I deleted the first message in the thread but changed my mind, so I did ctrl-Z (undo). However, when it came back it had the same subject etc. as the second message in the thread. Then when I collapsed the thread (hit the - box), one of the messages in the thread just disappeared. When I expanded the thread (hitting the + box), a message below the thread disappeared. Every time I toggled the thread +/- box, another message disappeared. I went to a different mailbox and came back, and all the messages were restored (including the original two message thread). When I tried to reproduce it, I was unable to do so. I tried reproducing it in the original mailbox and a few other mailboxes, but threading now seems to work fine. I tried closing Thunderbird and re-opening, to reproduce it, but was unable to.

I'm still experiencing this in 0.7 on OSX. Not sure how to nominate this as a blocker, so I just set a target milestone for this to 0.8. I hope that's OK, since this bug really interferes with usability, at least for me.

System: Windows 2000 Thunderbird version: 0.7+ (20040712) Reproduceable: yes Maybe not quite the same bug, but might be related... I also experience some strange behaviour related to thread sorting. I was able to reduce this reproducible case to 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. Changing the view to e.g. "Sorted by date" will show all the thread's mails, so these mails only disappear from the threaded view and not altogether from the folder. 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. But after manually moving some of the thread's follow-ups to another folder and back suddenly everything works as expected, all the time.

Bart, do you use IMAP or POP3? Are you viewing all messages, or just unread? Are your threads sorted normally (i.e., with oldest threads first?). Do you ever use Windows builds, and if so, do they have this problem?

After talking to Bart, we decided it's quite possible that this happens when he undoes a delete - he undoes and redoes deletes very often. What happens is that the msg hdr we undo the delete for already has a thread parent set, when we pull it out of the undo queue - this needs to be cleared so that we'll figure out the thread parent correctly....

Comment on attachment 155089 [details] [diff] [review] proposed fix probably lots of dups of this bug.

Comment on attachment 155089 [details] [diff] [review] proposed fix bart will be so happy.

this will change my life :) david and I just ran through an occurrence of this bug. hopefully we're one step closer.

I believe the view counts could also get off when a new message gets added as the parent of an already open thread - this scenario was generating an assert in the tree code. This patch fixes that by making sure we notify the tree about the insert of the new top level message. I'm not sure if this could cause the problem Bart sees, but it's not good for the count to get off.

Bart, can you try tomorrow's tbird build (trunk or branch, either one) and let me know if you still see this? I'm not sure if either of these fixes will get rid of what you saw, but it's worth a try.

version 0.7+ (20040807) I still see the bug as described above. Should I file a separate bug report as this seems to be a slightly different problem? Please advise. :)

i'm running the 8/5 build and haven't seen the threading bug yet. I'll let you know if I encounter it again. i'm hopeful.

Bart has not seen this in a week - marking fixed, tentatively...

re-opening - Seth and I found another problem in this area...patch upcoming

this fixes a problem I see when opening a folder that's sorted flat (e.g., by date or subject) and then switching to threaded mode. Some messages are indented that shouldn't, and some don't have thread icons that should (seemingly). This patch fixes the indentation. I'm not sure if this fixes the delete problem, but it fixes the bogus indentation (not sure why the code as it was doesn't work - that's another thing I need to figure out)

yet another fix - this fixes the case where new headers arrive into a flat-sorted folder (e.g., by subject) after the folder is opened, and then we switch to threaded view. Sometimes we weren't noticing that the new header arrivals made one or more of the threads into threads with children, and things degenerated from there.

this fixes the problem on the trunk.

fixed on trunk.

Comment on attachment 159587 [details] [diff] [review] trunk version of fix >+ if (numExpanded > 0) >+ m_flags[j - numExpanded] = flags | MSG_VIEW_FLAG_HASCHILDREN; This part of the patch is unnecessary because it's in an if block that has already checked for the MSG_VIEW_FLAG_HASCHILDREN bit.

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