268572 - Sorting by thread can cause newer messages to disappear from list

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Matt Davis]

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.

Comment 1

[Mike Cowperthwaite]

(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.

Comment 2

[Matt Davis]

(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

Comment 3

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

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

Comment 4

[Wayne Mery (:wsmwk)]

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

Comment 5

[Matt Davis]

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