Sorting by thread can cause newer messages to disappear from list

NEW
Unassigned

Status

MailNews Core
Backend
14 years ago
9 years ago

People

(Reporter: Matt Davis, Unassigned)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

13 years ago
(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.
Assignee: mscott → sspitzer
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → MailNews: Backend
Ever confirmed: true
OS: Windows XP → Windows 2000
Product: Thunderbird → Core
Version: unspecified → Trunk
(Reporter)

Comment 2

13 years ago
(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.
Assignee: sspitzer → nobody

Updated

10 years ago
QA Contact: backend
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core

Comment 4

9 years ago
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
(Reporter)

Comment 5

9 years ago
I can confirm that the problem is still present in Thunderbird 3 Beta 2 (en-US/Windows XP)
Duplicate of this bug: 420591
You need to log in before you can comment on or make changes to this bug.