697478 - threads jump around

Status: RESOLVED DUPLICATE of bug 383985

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[a_geek]

In a mailbox, I have the following messages:

msg1 (time1)
msg2 (time2 > time1)

I have sorting set to Date, Ascending, Threaded. Now a msg3 arrives (time3 > time2), as an answer to msg1. As a mutt user, I expect the result to be:

msg1
  + msg3
msg2

But I get:

msg2
msg1
  + msg3

In other words, the threads jump around, since the date of the latest instead of first message seems to be used to calculate the sort order.

While searching for an appropriate bug, #254159 looked similar, but not quite the same.

Comment 1

[Hashem Masoud]

(In reply to a_geek from comment #0)
I checked few things and this is what I found out:
1. If the e-mail header contains In-Reply-To field, then Thunderbird keeps it in its thread.
2. If the e-mail header doesn't contain it, it will not be part of a thread.

This depends on the e-mail client creating the reply e-mail. So can you check the header of msg2 if contains the field In-Reply-To or not?

Comment 2

[David :Bienvenu]

if I'm understanding you, this is by design - when a new message comes into a thread, we move that thread to where it should be, based on date of the newest message in the thread.

Comment 3

[a_geek]

wrt. comment#1: msg2 is not part of the thread, so this is not a problem.

wrt. comment#2: I understand that this behaviour is by design, but I contest the design decision. If sorting order was by "Received", then I'd accept that the threads are jumping around, but if sorting is by "Date", they shouldn't, and the first, not last, message should determine where the thread gets sorted.

Comment 4

[David :Bienvenu]

cc'ing Blake, but this behavior was highly requested, so I don't think it will be reversed.

Comment 5

[a_geek]

Current behaviour:

Threading + Sorted-By-Date == Threading + Sorted-By-Received

(ie, one option would be redundant), and desired behaviour:

Threading + Sorted-By-Date != Threading + Sorted-By-Received

for improved functionality and orthogonality at the same time.

Do you have a pointer as to where the functionality was requested? I mean, what would be the point in eliminating one option altogether?

Comment 6

[a_geek]

I'm still experiencing the problem with TB8, and it makes sorting by thread halfway useless. If you don't want to change the default behaviour, it would be great to have something to flip in about:config.

Comment 7

[Wayne Mery (:wsmwk)]

Blake?

(In reply to David :Bienvenu from comment #4)
> cc'ing Blake, but this behavior was highly requested, so I don't think it
> will be reversed.


(In reply to a_geek from comment #6)
> I'm still experiencing the problem with TB8,

of course you are. because nothing has changed.
please don't spam the bug with unproductive updates.

Comment 8

[Wayne Mery (:wsmwk)]

So the request is sort order to be based on the latest message received, while the current behavior is comment 2 and won't be changed. 

Is the request a duplicate of bug 383985?

Comment 9

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #8)
> So the request is sort order to be based on the latest message received,
> while the current behavior is comment 2 and won't be changed. 

I didn't read it that way. Per comment 1, and what I see on my local POP accounts, current thread-sorting behaviour IS based on DATE header of latest message, i.e. the whole thread containing message with newest DATE header will fall into the position of that Date, regardless of age of thread (Date header of first msg in thread). Reporter's problem is that he can't sort threads by age of thread (Date header of first msg in thread). Which looks like problem described in Bug 383985 Comment 5.

The current "workaround" for sorting by "age of thread" seems to be sorting by "Order received" instead of "date", but I agree with reporters of this bug and bug 383985 that this is unintuitive, undiscoverable, and inconsistent (and per WADA's comments will probably fail if you moved your messages around between folders in the wrong order, which will break "order received" which is sometimes based on message offset in folder. To complete the confusion, I also see a different field "received" which hopefully represents the "Received header").

> Is the request a duplicate of bug 383985?

I think yes.

Comment 10

[Thomas D. (:thomas8)]

(In reply to a_geek from comment #5)
> Current behaviour:
> Threading + Sorted-By-Date == Threading + Sorted-By-Received

FTR, I don't see that. For me (local POP3, without moving many msgs in and out of folders which changes offset):

Current behaviour:
Threading + Sorted-By-Date != Threading + Sorted-By-Received

> (ie, one option would be redundant), and desired behaviour:
> Threading + Sorted-By-Date != Threading + Sorted-By-Received
> for improved functionality and orthogonality at the same time.

Behaviour desired by reporter is what I see currently, but it's not good behaviour imo because it ties things in strange ways (bug 383985)

Comment 11

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #10)
> (In reply to a_geek from comment #5)
> > Current behaviour:
> > Threading + Sorted-By-Date == Threading + Sorted-By-Received
> 
> FTR, I don't see that. For me (local POP3, without moving many msgs in and
> out of folders which changes offset):

On TB 17.0.2, WinXP.