User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041108 Firefox/1.0 Build Identifier: version 0.9 (20041103) After deleting the root of a mail thread and resorting the child disappears. Reproducible: Always Steps to Reproduce: 1. Sort inbox by thread 2. Send yourself and email with the title "123" 3. Send yourself and email with the title "456" 4. Wait a few seconds and send yourself another mail with the title "123" and something in the body. 5. Wait for mail to arrive. 6. Delete the "123" message without the body 7. Resort folder pressing the speech-bubble column header twice. 8. Select another folder and reselect the Inbox Actual Results: 5. It will be correctly sorted as follows (assuming new threads at top) - 456 - 123 [no body] \- 123 [with body] 6. The newer "123" replaces the deleted message. It should be above 456, but I can see why this isn't the case. 7. Message 123 disappears from the list 8. 123 is back in the list, and in the correct place. Expected Results: After performing step (7) the message 123 should be in the list and in the correct place.

(In reply to comment #0) These steps require the pref mail.thread_without_re to be True. However, the same results occur with threading of replies. > Actual Results: > 5. It will be correctly sorted as follows (assuming new threads at top) > - 456 > - 123 [no body] > \- 123 [with body] Do you mean "correctly" or "incorrectly" there? This is the expected sorting at this point. > 6. The newer "123" replaces the deleted message. It should be above 456, but I > can see why this isn't the case. "123" is not above "456" because items are not resorted in response to actions like Delete. > 7. Message 123 disappears from the list Yep, it sure does. Resorting, or turning off threads, does not cause the missing message to re-display. Reproduced with TB 1.0+0325 and with Moz 1.8b2-0309, Win2K. Moving to Core.

(In reply to comment #1) > (In reply to comment #0) > > These steps require the pref mail.thread_without_re to be True. However, > the same results occur with threading of replies. > > > > Actual Results: > > 5. It will be correctly sorted as follows (assuming new threads at top) > > - 456 > > - 123 [no body] > > \- 123 [with body] > > Do you mean "correctly" or "incorrectly" there? This is the expected sorting at > this point. Yes, "correctly". > > 6. The newer "123" replaces the deleted message. It should be above 456, but I > > can see why this isn't the case. > > "123" is not above "456" because items are not resorted in response to actions > like Delete. I wasn't sure whether or not sorting should have taken place. As you say, it is sensible not to sort. > > 7. Message 123 disappears from the list > > Yep, it sure does. Resorting, or turning off threads, does not cause the > missing message to re-display. > > Reproduced with TB 1.0+0325 and with Moz 1.8b2-0309, Win2K. Moving to Core. Thanks, I'm still learning the bug system and components

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Matt, can you check if this still occurs for you and update the bug? If it does, please try beta 2 which fixes a lot of threading issues and post results - http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ If it does not occur, please close bug with resolution set to WORKSFORME

I can confirm that the problem is still present in Thunderbird 3 Beta 2 (en-US/Windows XP)