Counter intuitive ordering for threaded Email ordered by "order received'

[Dennis S]

Binary package hint: mozilla-thunderbird

-> Go to the inbox, set your view to threaded and your sorting to order received
-> Receive an email to an older thread

The thread will remain in the same spot in the list, even though of its children is my most current email and should be on top.

The correct way to do this would be to have the entire thread move up to the top, based on the received status of the children in the thread view.

ProblemType: Bug
Architecture: i386
Date: Wed May 16 19:02:39 2007
DistroRelease: Ubuntu 7.04
Package: mozilla-thunderbird 1.5.0.10-0ubuntu3
PackageArchitecture: i386
SourcePackage: mozilla-thunderbird
Uname: Linux dennis03 2.6.15-25-686 #1 SMP PREEMPT Wed Jun 14 11:34:19 UTC 2006 i686 GNU/Linux

[Marko-macek (marko-macek)]

This seems to be dup of bug 20385.
And in latest thunderbird release "sort threads by date" seems to work correctly.

[Cross-distal (cross-distal)]

This is not quite a dup, tho thank you for pointing that out. That bug appears to apply to sorting by
Date, but not to sorting by "Order Received". Sorting by Date allows the spam that set their own
random Date: header data to be in unexpected places. For largely that reason, I use "Order Received"
as my sort. If the fix for bug 20385 could be applied to affect "Order received" as well, then this bug
would be fixed as well.
That's the FE I'm R'ing. :-)

[Cross-distal (cross-distal)]

So, has anyone had a chance to think about this? I've realized that it's
substantially more complicated than changing the way "sort by date" works, since
you just had to create a new "date" field used to sort the thread. Is sorting
by "order received" implemented as sorting by message number? Or sorting by
position in the stream? If the former, it's enough like "date" that the same
could be done.
Anyone know how it's implented currently, internally?

[Marius-e (marius-e)]

There seems to be a lot of misunderstanding about this bug.

I've come to confirm this report, as I've also used Mail.app on OS X, and dearly
miss this behaviour.

Put it like this:

1) Closed threads should display the date of the latest message.
2) Threads (closed and opened) should be sorted in the list by latest message date.

This should work for both received date (ala. SPAM) and sent date.

This is a problem since when someone replies to a long-dormant thread, it is
VERY difficult to find/see this mail message, especially since it's not very
clear when there is a new message in a thread. (The underline is really not that
visible)

I hope this explanation is a bit more clear...

[Mozilla-jgvons (mozilla-jgvons)]

I like to add two items to comment #4:

3) when new messages arrive the mailbox threaded view should be reordered
automatically so that old threads with new messages automatically jump to the
end of the list (when sorting by date or order received).

4) threading is not really a sort criterion but a way to present messages: it
should therefore be an option that allows a user to choose between presenting
messages individually or grouped/threaded. A mail folder can then be sorted on
any of the date/sender/subject/... criteria, both in the threaded and in the
unthreaded view.

Note also that bug #20385 only implements the thread-by-date partially, since it
doesn't re-order the folder when new mail comes in. One either has scan the
whole folder to find the thread with the new message, or click again on
view->sort-by->date to force a "re-sort" of the folder; either solution is
cumbersome, this should be automatic.

[Mcow (mcow)]

Sorting in a threaded view is, currently, almost always performed on the topmost
message in the thread. The one exception is Date, in which case the most recent
message is used to determine the thread's position.

It would probably be reasonably simple to use the same criterion for Order
Received sorting. That seems to be what reporter is seeking, and it makes as
much sense as the current sorting, so why not.

But adding a preference, let alone a checkbox, to control this makes little
sense.

Comment 4 and 5 expand on the original report far beyond what Reporter had to
say about this issue.

(In reply to comment #4)
> There seems to be a lot of misunderstanding about this bug.

If you had opened this bug, you would be justified in making that statement.

> 1) Closed threads should display the date of the latest message.

How do you display a thread view with some threads expanded and others
collapsed? The top message in the thread shows its own date for expanded
versions, and the latest date for collapsed versions? This is confusing, and I
would not like it.
Alternately, it would require a new column, "Latest Thread Date" or something.
This column would only be useful for threaded views and, in my opinion, would
take up far too much real-estate for very little gain.

> 2) Threads (closed and opened) should be sorted in the list by latest message
> date.

That's what happens now, if you sort Threads by Date.

> This should work for both received date (ala. SPAM) and sent date.

Well, first Received date needs be made available -- bug 166254, bug 216033. I
really don't see the point, myself; Order Received does the trick for locating
spam, and for anything else I can't see why the very infrequent misdated message
requires adding an entire new sort.

> This is a problem since when someone replies to a long-dormant thread, it is
> VERY difficult to find/see this mail message

But that has nothing to do with Received date, and it has nothing to do with
displayed date. If you sort your threads by date, and/or if you use
  View | Threads | Threads with Unread
it's fairly easy to locate the new stuff.

(In reply to comment #5)
> 3) when new messages arrive the mailbox threaded view should be reordered
> automatically so that old threads with new messages automatically jump to the
> end of the list (when sorting by date or order received).

This is bug 262319, and as I commented there, this would not be a good idea.
If I'm reading a message, I don't want the thread pane jumping around,
distracting me, as new messages arrive.

> 4) threading is not really a sort criterion but a way to present messages: it
> should therefore be an option that allows a user to choose between presenting
> messages individually or grouped/threaded. A mail folder can then be sorted on
> any of the date/sender/subject/... criteria, both in the threaded and in the
> unthreaded view.

This is exactly how Mozilla/TB behave now. Threading and sort criteria are
separate. It's true that, by default, clicking the Thread column header also
resorts by Order Received, and clicking any other header unthreads -- but this
behavior can be changed: see bug ...

[Marius-e (marius-e)]

It's quite simple really. The original poster said:

>> but have the *latest* descendant of a thread (when using threaded view)
>> effect the sort

This is my main problem (but not only).

No switch or config option is required for this. You just need to change the
core behaviour of this. The way it's currently implemented may be logical, but
there is no real reason for this to be handled as is.

Currently the threaded view sorts the thread in the list by it's oldest
message... this is useless. It should be sorted by the latest (newest)
message... this is useful (and also the default behaviour of other major mail
clients (Mail.app, Gmail, Mutt) ... for a reason.)

I for one do not *really* need or require order-received dates, all I meant was
the above behaviour with threads and sent dates should also be applied to
threads and (order-)receive dates suggested by the original poster. (But this
was not my main point and can be ignored.)

This should be a fairly simple change to make (No UI change at all), and I said
there was a lot of confusion because people in this thread had sometimes
conflicting notions of the core of the problem and did not address some of the
issues of the original poster. I just thought that since the poster and myself
both have used Apple Mail.app in the past, I found that this problem report was
very similar to my issues and thus I would re-enforce some of the points in the
original post which seemed to have been neglected. Is all.

I'm not using Thunderbird so much anymore, since GMAIL's discussions (threads)
work correctly and the searching is much more convenient. On both counts Apple
Mail.app is similarly endowed.

[Cross-distal (cross-distal)]

Excellent to see some commentary on this. I've just returned from vacation, and will try to respond:
From Comment #4:
1) Apple's Mail does this, but I don't think I care much what's displayed when the thread is closed. But,
if the sort is affected by the last "order received" (not really date, in this case), then it makes sense to
display the date of the last message in the thread (by order-received sorting).
2) -Umm- this is confusing. It confuses the original RFE. Please ignore it.

And it goes on to talk about the "received date (ala. SPAM) and sent date". This is confusing, as well.
The "sent date" is the date it was sent, from the mail Date: header. That's what spam mucks with. The
received date is the envelope time-stamp, and is different. I have no desire for a "received date" sort,
as "order received" does this fine for me, as indicated in a later comment.

w.r.t. Comment #5:

I think I understand all of this and agree. I definately want the headers to resort when new mail comes
in. Doesn't this already happen? If it does normally, and the fig for bug 20385 doesn't cause that to
happen when doing a threaded presentation of mail sorted by Date; then I'd argue that as a bug. [This
is later noted to be bug #262319]

Mike (comment #6):

  I am also hoping it would be easy to add this functionality to "Order Received" sorting, much as bug
20385 implemented it for Date sorting. And, while your point about finding things using "threads with
unread" does solve that problem, it's not what I want to do typically. I'd just like "active" threads to be
moved to the bottom of the sort. Thus the RFE.

Thanks. I would be happy to see the default sort for things to have it done this way. I'm not sure
there's much advantage to the current system. But, in case other people liked the current system, I
suggested it be an option. Vote me accepting of having it be the "new" behaviour with no way to switch
it back. :-)

[Cross-distal (cross-distal)]

Is there any status on this? Does anyone have time to look into changing this
behaviour? It's getting to the point where I'm considering looking for other
applications that sort this way, because it's nearly impossible for me to find
email I need to deal with based on "recentness". The things I typically look
for aren't unread, but just recent, and it makes it harder to find things if the
list of visible headers is increased by turning off threading. (And, I don't
really want to have to affect the view/sort style just to find something, so I
can then switch it back to the mode I prefer)
I'd appriciate any feed back, or better yet someone to suggest code to implement
the request...

[fantasai (fantasai)]

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

[Mcow (mcow)]

fantasai: as noted in comment 6, when threads are sorted by date, they *are* sorted by the date of the most recent message in the thread.

[fantasai (fantasai)]

Then close the bug as fixed; judging by the reporter's comments I think the summary is accurate.

[Cross-distal (cross-distal)]

No. This bug is still unresolved. For nearly two years now.
Please read the original report. I would like the behaviour that *does* exist when sorting by date, to also apply to other sorting methods. Specifically, sorting by "order received", often called by other mailers "Date received" (ie, *not* date sent, or the potentially bogus Date: header)
If you sort by "Order Received", the thread still sorts by the order of the *first* member of the thread, not the last.
Please do not close this bug, which may in fact still be an RFE as was previously indicated by the subject, as it is still an issue.

[Mcow (mcow)]

Resummarizing specifically for the Order Received case.

[Digulla-hepe (digulla-hepe)]

Can this please be fixed soon? I lost a couple of very important mails because TB sorted them into very old threads :-(

[Digulla-hepe (digulla-hepe)]

Any chance to have this in 2.0?

[Gervase Markham (gerv-mozilla)]

Steps to reproduce:

- Pull down Thunderbird thread page column picker and choose "Order Received",
  so you can see
- Click the header of the thread column to sort by thread

Expected: Date column acquires "sort arrow"; Thunderbird sorts the threads in order of "earliest date in thread". After all, threading is an inherently date-based thing.

Actual: Order Received column acquires "sort arrow"; Thunderbird sorts the threads in order of "lowest order-received number in thread".

I don't know how the order received numbers are allocated, by as they are not congruent with date, you can get some very strange sort orders. Examples and screenshots available on request. This is particularly bad if you are the sort of person who triages their inbox into a "to do" folder, because the Order Received number gets reallocated whenever you move a message from one folder to another.

This may be a duplicate of or related to bug 57898, but I'd like a Thunderbird developer to comment on this particular common scenario.

Gerv

[Mcow (mcow)]

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

[Mcow (mcow)]

This behavior is "how it's always been" in the suite as well as TB.

If you set the value of the pref
  mailnews.thread_pane_column_unthreads
to False, clicking the Thread column header won't change the sort criterion; it will simply toggle between Threaded and Unthreaded. By default, this pref is True to provide the old behavior. (xref bug 219787.)

Additionally, clicking on any other column header won't change the threading, it will simply change the sort criterion or reverse the direction.

The suite additionally provides prefs UI for changing that setting.

[Gervase Markham (gerv-mozilla)]

Mike - thanks for that. Changing that pref helps - in that I can sort by date and then thread, and get the behaviour I want. But it doesn't solve the underlying problem.

"This is how it's always been" is true of many things, including a load of long-standing bugs. It doesn't make it necessarily right. Has anyone come up with a reason why people might ever want to sort by the date/time a file has arrived in a folder? Or might (without the hint of the column being present) even *guess* that this is what's going on? Do we know of any other mailers that behave that way?

The default sort should be by the date on the mail, not by order received.

Gerv

[Mkmelin+mozilla (mkmelin+mozilla)]

Sounds like a duplicate of bug 262316.

[Mcow (mcow)]

I believe Gerv is talking about which order the threads appear in relative to one another; that bug is about ordering of the items within the thread.

[Gervase Markham (gerv-mozilla)]

Exactly.

Gerv

[Mcow (mcow)]

> Has anyone come up with a reason why people might ever want to sort by the
> date/time a file has arrived in a folder?

I'm speculating that this happened primarily because the developers of the Netscape era were dogfooding with IMAP, where (if I understand this correctly) "order received" *is* "date received" even for messages moved to folders.

Similarly, Order Received is the tiebreaker for all other sort criteria -- subject, sender, whatever (xref bug 363991). Arguably, that should be "by date" as well.

Also: it used to be that threads sorted by date used the date of the topmost item in the thread, so sorting by date didn't necessarily gain you anything in terms of visibility of recent messages -- in which case, sorting by Order Received isn't much worse. That behavior was changed (around the time of Mozilla 1.5, I think) to use the most-recent item in the thread. (Bug 254159 seeks the same technique for using Order Received sorting.)

Even sorting by date is contentious -- see bug 166254. A lot of people want sort by "Received Date" because Date headers are often broken; others want the Date header to always be used.

Anyway, Gerv: the patch at bug contains the line that sets the sort criterion for sort-by-thread with unthreads=False:
  sortType = nsMsgViewSortType.byId;
If you want to submit a patch and drive it past the gauntlet, more power to you.

[Nelson-bolyard (nelson-bolyard)]

Duplicate of bug 264941 ?

[Nelson-bolyard (nelson-bolyard)]

See also bug 341548 (especially bug 341548 comment 10). It's related to
the symptom of messages being (or appearing) out of order. David Bienvenu's
patch for that problem is attached to bug 166254 (which it also fixes).
It has been waiting there for SR for 15 months. Maybe a governance issue?

[Mcow (mcow)]

(In reply to comment #6)
> Anyway, Gerv: the patch at bug contains the line that sets the sort criterion
> for sort-by-thread with unthreads=False [...]

s/b: ...patch at bug 219787 ...
                      ~~~~~~
(Gerv asked me about this in email, and I think I responded to him with the wrong bug #. 219787's patch contains the source line quoted at the end of comment 6, shown moved from one location in the logic to another.)

(In reply to comment #7)
> Duplicate of bug 264941 ?

No, that bug is about changing to 'Order Received' in response to selections in the View|Threads menu. (Incidentally, the patch there was just checked in this morning.)

(In reply to comment #8)
> See also bug 341548

Not related. This bug is specifically about picking which sort mode is chosen in response to the click on Thread column header when unthreads=true. That bug is about which date-containing header is used to fill in the Date header. (Also, that bug has been fixed.)

[Dennis S (dennis-dennisschaaf)]

Binary package hint: mozilla-thunderbird

-> Go to the inbox, set your view to threaded and your sorting to order received
-> Receive an email to an older thread

The thread will remain in the same spot in the list, even though of its children is my most current email and should be on top.

The correct way to do this would be to have the entire thread move up to the top, based on the received status of the children in the thread view.

ProblemType: Bug
Architecture: i386
Date: Wed May 16 19:02:39 2007
DistroRelease: Ubuntu 7.04
Package: mozilla-thunderbird 1.5.0.10-0ubuntu3
PackageArchitecture: i386
SourcePackage: mozilla-thunderbird
Uname: Linux dennis03 2.6.15-25-686 #1 SMP PREEMPT Wed Jun 14 11:34:19 UTC 2006 i686 GNU/Linux

[Gervase Markham (gerv-mozilla)]

Yes. To be completely clear:

Currently, when unthreads=true, the sort mode chosen when one asks for threads is "Order Received". This works poorly in the Inbox and even worse in other folders, because it gets reset when a message moves between folders.

This bug requests that, when unthreads=true, the sort mode chosen when one asks for threads is "Date".

I strongly suspect this is a one-line change somewhere. Anyone know where?

Gerv

[Fredrik (fredrk)]

The issue is still present in 2.0.0

This is my BIGGEST concern right now. If the thread sorting was sorted out as it should do Thunderbird would be a killer app. As it is now it's just "it works...".

I see no reason why threads not should be sorted after the date on the e-mail last received. Sorting on the first e-mail is plain silly.

I want tou be abled to use threaded view but Thunderbird makes it totally impossible as you always miss important mail 356 pages up ...

[Fredrik (fredrk)]

This is just tragic:

Reported: 2004-08-03 08:50 PDT by Chris P. Ross

That is ages ago and threaded view i still USELESS.

[Marius-e (marius-e)]

Hehe, yup, This is such a *basic* but *vital* feature. I don't think the Thunderbird project has any spare capacity or something.

I reported this 3 years ago, and after using it for about 4 months I decided to move on. Seems that was a good choice... I'm very happy with my current mailer.

Sorry guys, but it seems this project is only alive in all the wrong places...

[Digulla-hepe (digulla-hepe)]

Especially since the same behavior works when you sort by "Date" (which can be
forged, corrupt or missing). Only sorting by "Order received" is broken.

[Digulla-hepe (digulla-hepe)]

To anyone in the CC list of this bug: Please vote for it (there is a small link "vote" at the top) and get anyone you know to vote on this bug so it gets fixed.

[Marius-e (marius-e)]

Sweet, Will do.

[Fredrik (fredrk)]

About comment 21:

No, the thread sort is broken for "Date" too.

It sorts ok when started but when new mail arrives, the sorting breaks.

[Torhu (torhu)]

(In reply to comment #24)
> About comment 21:
<snip>
> It sorts ok when started but when new mail arrives, the sorting breaks.
>

This is a different issue, reported here:

https://bugzilla.mozilla.org/show_bug.cgi?id=352639
https://bugzilla.mozilla.org/show_bug.cgi?id=357850

[Aletsm (aletsm)]

Hi,

Any update on this? at least an ID for this features?

A/

[M-wada (m-wada)]

FYI. Seamonkey version is Bug 389935.

[Bugzilla-game-point (bugzilla-game-point)]

I have a working patch for this bug. It depends on the fix for Bug #166254 being checked in first, though. It sorts by Received when possible, otherwise by Date. I'll post it when Bug #166254 has been fixed.

By the way, it only jumps to 'order received' if you click the thread column button. If you sort by Date, then choose 'View | Sort by | Threaded', it still sorts by date.

[Bugzilla-game-point (bugzilla-game-point)]

I'd recommend WONTFIXing this bug, and here's why...

The reason you want to sort threads by the Order Received of the latest thread is because Date is unreliable, correct?
> Sorting by Date allows the spam
> that set their own random Date: header data to be in unexpected places.

Order Received is not a particularly good alternative as it tends to get changed by Thunderbird as mails are moved around in folders, and it's useless when you're importing a load of e-mails from somewhere else. The best solution is instead to use the Received header for sorting, which is added by the MTA, and is therefore much more reliable. Spams won't be able to fake that date.

(In reply to comment #8)
[...]
> The
> received date is the envelope time-stamp, and is different. I have no desire
> for a "received date" sort,
> as "order received" does this fine for me, as indicated in a later comment.

I think you're misunderstanding 'Received date', as it is indeed much more useful than 'order received'. It basically obsoletes sorting by order received.

Now, you may be asking me how you sort by received date. You can't... yet. However, the good news is that a fix for Bug #166254 is about to be checked in, which will allow you to!

I'd also echo the comment made by Mike Cowperthwaite:
> Sorting in a threaded view is, currently, almost always performed on the
> topmost message in the thread. The one exception is Date, in which case
> the most recent message is used to determine the thread's position.

In other words, dates are a special case. I think we can extend that special case to the Received date as well as Date, but Order Received isn't a date and should probably be ordered, like all other fields, according to the value of the topmost thread message. Ordering by Received date, I believe will do what you want. Just wait for that patch to be checked in and use Received date.

[Bugzilla-game-point (bugzilla-game-point)]

PS. Forgot to add, this applies to POP and IMAP e-mails only. For newsgroup messages, you should order by Date, because news Dates are added by the news server, not the sender of the post, and are therefore reliable.

[Fredrik (fredrk)]

> The reason you want to sort threads by the Order Received of the latest thread
> is because Date is unreliable, correct?

No, not at all.

The bug is that Thunderbird sort the threads on the first e-mail in the thread, not the last. Which date this is, is an other question. When sorting on the first e-mail threads tend to dissapear. The "Mutt" model is much better. The threads with new e-mails will always stay in sight.

Thunderbirds thread model, as it works today, is TOTALYY usless. You always lose new an important mails because these belong to a thread started several weeks ago.

[Bugzilla-game-point (bugzilla-game-point)]

(In reply to comment #28)
> No, not at all.
>
> The bug is that Thunderbird sort the threads on the first e-mail in the thread,
> not the last.

No it doesn't, if you're sorting by Date, and then threading.

[Fredrik (fredrk)]

Did last time I checked.

The sorting is correct after resorting but when a new e-mail is received it breaks.

[Bugzilla-game-point (bugzilla-game-point)]

It doesn't move e-mails around live, no. I'm not sure why, probably the developers thought it was to inefficient, or too much hassle.

However, once you receive the new e-mail, close Thunderbird and reopen it. Go back to that folder. The threads will now be ordered correctly.

[Fredrik (fredrk)]

> However, once you receive the new e-mail, close Thunderbird and reopen it. Go
> back to that folder. The threads will now be ordered correctly.

And THAT is effective way working with e-mails?

The bug is still there.

[Bugzilla-game-point (bugzilla-game-point)]

So you now realise that Thunderbird *does* order the e-mails correctly, just not immediately; but it does once you close and restart.

This is a totally different bug to the one filed here. The one filed here is to do with the way Thunderbird sorts threads when sorting by Order Received. If you have a problem with Thunderbird not immediately resorting threads when new mail is received, please file a new bug about it. *This* bug, however, should be WONTFIXed.

[Cross-distal (cross-distal)]

In response to Jeremy's comment #26:
> In other words, dates are a special case. I think we can extend that
> special case to the Received date as well as Date, but Order Received
> isn't a date and should probably be ordered, like all other fields,
> according to the value of the topmost thread message.

  So why is this? In what cases are sorting by the topmost thread message better than the bottommost? Admittedly, sorting by Size, or Subject, or many other things is less common, and with threading on will be very confusing anyway. If you choose to sort by Size, does Thunderbird maintain a threaded view? Presuming it does, what Size should it sort by? I would argue that Apple's "size of the thread in total" makes sense, but that might require a fair amount of additional code. And, in the case of a thread, what does define which message is "topmost" and which is "bottommost"? Order received, I assume? Mutt allows you to effectively set a secondary, thread-internal, sort, IIRC.

Ahh, I see, this is bug #262316. This changes it to be always date-based, rather than order-received-based, which just changes the problem. Especially if the GetDate that's being used by that new patch doesn't get changed to use the Received Date you're mentioning here (bug #166254).

> Ordering by Received date, I believe will do what you want. Just wait
> for that patch to be checked in and use Received date.

That would be fine. I'm happy to use Received Date instead of Order Received.

And re: comments #29-33; the fact that Thunderbird doesn't update the sort when new messages are added will still make this system very hard to use. Even with this improvement and change of configuration, which will fix the original problem at startup, if you leave Thunderbird running and receive mail on an old thread, the same problem occurs. I can accept that that's a different bug though. I'm sure it's already open more than once, if someone could place a reference here that would be useful.

[Bienvenu (bienvenu)]

you don't have to restart - you just have to re-open the folder, i.e., select something else in the folder pane, and then re-select the folder.

We don't resort when things change to avoid having the thread pane jumping around, to avoid the selection moving, etc. I realize some people want this behavior, and maybe we can make it optional.

[Nelson-bolyard (nelson-bolyard)]

> It sorts by Received when possible, otherwise by Date.

That description, if correct, does not sound like a fix for this bug.
It sounds like it makes things worse.
Which is wrong: the description, or the proposed fix?

[Mcow (mcow)]

(In reply to comment #32)
> > However, once you receive the new e-mail, close Thunderbird and reopen
> > it. Go back to that folder. The threads will now be ordered correctly.
>
> And THAT is effective way working with e-mails?
>
> The bug is still there.

But, it's NOT THIS BUG. See bug 262319

[Bugzilla-game-point (bugzilla-game-point)]

It's better than the fix for this bug suggests, because Received date is what people really want Date to be - a much more reliable indicator of when the e-mail really was received. I wouldn't say it makes things worse. Received date is not the same as Order Received.

[Bugzilla-game-point (bugzilla-game-point)]

(In reply to comment #34)
[...]
You asked...
> So why is this? In what cases are sorting by the topmost thread message
> better than the bottommost?

And you answered...
> sorting by Size, or Subject

> If you choose to sort by Size, does Thunderbird maintain a threaded
> view?

Yes.

> Presuming it does, what Size should it sort by?

Given that it's not obvious what entry's size you really want to sort by, I'd say sticking with the topmost thread entry's size is as sensible as anything else.

> I would argue that
> Apple's "size of the thread in total" makes sense, but that might require a
> fair amount of additional code.

Correct.

[Mcow (mcow)]

> Received date is what people really want Date to be

You're not necessarily correct in that assertion.

I don't see, at this point, why your patch needs to be dependent on whatever's going on with Received date is a mystery to me. The patch I made for
bug 264941, which implemented the menu behavior you cite in comment 13, simply preserves whatever the original sorting mode was. Do the same thing, don't change the sort criterion at all.

[Nelson-bolyard (nelson-bolyard)]

This bug very clearly says that the sort order should be by Date.
That's the Date in the Date: header.
That's how this product has worked ever since the beginning of the
Netscape/mozilla/SeaMonkey/Thunderbird product line.
That's how the vast majority of users expect it to behave.
It has recently regressed. This bug addresses the regression.
Using this bug as an opportunity to change the long-time behavior
of the product to suit your personal opinion of a "better" way to
work neither fixes the bug, nor suits the built-up community of
users of Mozilla mail/news clients.
And don't even THINK of saying "but that's how Outlook Express works"!

[Digulla-hepe (digulla-hepe)]

As I see it, this bug here can be closed as FIXED. The original problem with 1.5 was that there was no way to sort threads by order received *of the last post in the thread*. It would always sort after the *first* message of the thread. This works in 2.0.

The automatic reordering of the thread pane is a different issue (see bug 262319) and, personally, I'm absolutely unsure if I would even try such a feature. For me, it's okay to have to click on the folder from time to time to refresh the sorting. This way, I know when it shuffles things around. Just imagine what happens when TB updates the sort order while you select mails ... you might not even notice that a thread has just jumped into your selection range!

[Cross-distal (cross-distal)]

Aaron Digulla says (in comment #38):
> The original problem with 1.5 was that there was no way to
> sort threads by order received *of the last post in the thread*.
> It would always sort after the *first* message of the thread.
> This works in 2.0.

Umm, it does? I've tried using 2.0.x.y a few times, and it still has this problem. New messages in threads that were started months or years earlier are still *way* up in the sort. Does something special have to be done to make this work as you describe?

[Digulla-hepe (digulla-hepe)]

I stand corrected, it doesn't work. I just checked my settings and I'm using "Sort by date" ATM, this is close enough to what I need (unless the sender date is corrupt).

[Bugzilla-game-point (bugzilla-game-point)]

(In reply to comment #17)
> This bug very clearly says that the sort order should be by Date.
> That's the Date in the Date: header.
> That's how this product has worked ever since the beginning of the
> Netscape/mozilla/SeaMonkey/Thunderbird product line.

If you read the comments in this bug, apparently that's not true. 'How it has worked' is that it's used Order Received. However, most people have realised that 'how it has worked' is not always the best way, and that seems to be why this bug is here.

> That's how the vast majority of users expect it to behave.
> It has recently regressed.

Reading the comments to this bug, I don't see anything about a regression. It looks like the normal behaviour is to use 'Order Received'. There is a pref to stop that, but this is the traditional behaviour. I believe it should be changed because it doesn't work well.

> Using this bug as an opportunity to change the long-time behavior
> of the product to suit your personal opinion of a "better" way to
> work neither fixes the bug, nor suits the built-up community of
> users of Mozilla mail/news clients.

A Mozillazine vote will see about that. A *lot* of people prefer Received, maybe even the majority.

> And don't even THINK of saying "but that's how Outlook Express works"!

Bah. OE does a lot of things right. :-)

[Bugzilla-game-point (bugzilla-game-point)]

Created an attachment (id=281084)
Fix v1.0

I think the correct fix for this bug is not always to sort by 'Date', but to be consistent with the 'View | Sort by | Threaded' behaviour; that is, not to change the sort type at all. This patch does that.

[Bugzilla-game-point (bugzilla-game-point)]

PS. If/when this patch is landed, it fixes bug #389935 as well.

[Bienvenu (bienvenu)]

I'd much rather change the sort to byDate from byId, as the bug suggests, since I think your proposed behavior change is going to be very surprising for existing users. If I sort by sender to find an e-mail, and then turn threading back on, I'm going to be surprised, if I have your patch. I'd rather do the simple one line change.

[Bugzilla-game-point (bugzilla-game-point)]

David,

Why must you always focus so much on not 'surprising' old users rather than just improving behaviour? You're insulting their intelligence by implying that they can't adapt to this change. I don't even see any evidence in this thread that it ever did sort byDate, and especially with the new Received column having been added, I think sorting byDate is a bad move. You want that retarded one-liner, you write it.

[Eric Promislow (ericp)]

Running Thunderbird 2.0.0.6, I see that threads are sorted by
the timestamp on the first message in the thread, not the
most recent, even after I shutdown and restart (which is an
unacceptable proposal if it did work -- TBird is intended
to be left running).

[Bienvenu (bienvenu)]

(From update of attachment 281084)
minusing - I'll attach the simple patch in a sec...

[Bienvenu (bienvenu)]

Created an attachment (id=282722)
one-liner Asa was looking for...

I think this gives us the behavior people were looking for in this bug.

[Bugzilla-game-point (bugzilla-game-point)]

> Created an attachment (id=282722) [details]
> one-liner Asa was looking for...

I'm not sure what you've attached here, but I'm pretty sure it aint what you intended.

Moreover, why aren't you WONTFIXing this bug? Its desired behaviour is illogical, because people may want to sort by something other than date. How about accepting my patch for bug #397928 instead? Plenty of people agree with my behaviour, and when it comes to old behaviour vs easier/more intuative behaviour, you should be going for the latter. This is stuff being developer for a new *major* version of Thunderbird, version 3. It doesn't make sense to keep old stuff in for the sake of it.

[Bienvenu (bienvenu)]

Created an attachment (id=282728)
right diff...

oops, that was the wrong patch, thx for pointing that out.

I'm not wont-fixing this bug - I'm attaching the one line fix for the bug as described in the report. Your proposed patch is different from what is requested in the bug.

[Bienvenu (bienvenu)]

Created an attachment (id=282731)
geez, one day I'll get the right patch.

[Bugzilla-game-point (bugzilla-game-point)]

(In reply to comment #26)
> described in the report. Your proposed patch is different from what is
> requested in the bug.

... which is exactly why I created a new bug for my proposed behaviour. >:-(

[Alf (hubbuntu)]

Note that if you have the sorting set to 'date', this works as expected.

[Vseerror (vseerror)]

would be good to get this issue and bug 383985 sorted out, and decide if it is wanted for TB3

[Eric Promislow (ericp)]

Change my Comment #41 -- I changed the "Sort by" field from "Order received"
to "Date" and changed threads are now bubbling up to the top (or in
my case the bottom), just like Mail.app

A simple fix might be to use a sort type of "Date" instead of "Order Received"
when the user displays messages by thread.

[Eric Promislow (ericp)]

I just saw https://bugzilla.mozilla.org/show_bug.cgi?id=369620 --
that covers exactly what I asked for in Comment #42. I still
disagree on the current code's interpretation of "Order Received"
of a thread, but at least there's a workaround.

[Digulla-hepe (digulla-hepe)]

(In reply to comment #42)

> A simple fix might be to use a sort type of "Date" instead of "Order Received"
> when the user displays messages by thread.

As it was mentioned before, the drawback of this fix is that "Order Received" always works while "Date" depends on the sender having a correctly set up system clock. Spam, for example, sometimes has weird dates (not necessarily because they try to achieve something; more often than not, the zombie machine simply doesn't synchronize its clock because the owner doesn't care).

It's not a big deal since there are three kinds of bad clocks: Near the epoch (1.1.1970), around 2036 and around the current time (with an offset of a few hours because the system clock gets out of sync). So if you look at the newest mail, you get most of the mail with broken dates and you only have to check the other end of the queue once in a while to get them all.

That being said, I still can't understand why "Date" works while "Order Received" is impossible to fix. It's not as if the whole algorithm has to be implemented from scratch again. It's just a different header field that has to be used in an existing sort algorithm.

So when I saw this bug, I was sure it would be fixed as a minor issue in the next release. But instead, this bug is now four (*4*) years old!

Please see bug 426161 where I ask for a change in the development process to make sure that bugs don't get lost.

[Digulla-hepe (digulla-hepe)]

Scott, can you please shed some light on why you were unable to fix this issue for the last three years?

Or, even better, just fix it so this futile waste of time can finally be forgotten? It can't take more than an hour to fix.

[Mkmelin+mozilla (mkmelin+mozilla)]

He was only the default assignee. Feel free to provide a patch to make this a pref, I don't think most people would want it by default.

[Fredrik (fredrk)]

I think most people would like this as default, as a matter of fact, it't the only way to have it if you want a threaded view. As it is now the threaded view is USELESS.

[Fredrik (fredrk)]

I'm stuck with evolution until this is fixed. I think alot of people are waiting for a fix for this 4 years old issue.

[Marius-e (marius-e)]

lol, yea... I've given up on Thunderbird as an old cumbersome program... I've not looked back in years.

I'm still subscribed to this bug because it kept me amused.

It's becoming pretty sad now really... Think I'm going to unsubscribe.

Bye, guys... it's been fun.

[Justdave-mozilla (justdave-mozilla)]

If you haven't been watching the news, driving of the Thunderbird release process has recently gotten an infusion of cash, management, and development labor. Along with that came an effort to re-triage the existing bugs and get things back on the radar that may have been previously lost. And requesting the "wanted-thunderbird3" flag is the way to make sure the new triage effort sees it. (doing so now)

See http://ascher.ca/blog/2008/04/08/accepting-nominations-for-thunderbird-30a130-blockers/

[Mkmelin+mozilla (mkmelin+mozilla)]

Yes, this too would be good to get in. Bug 383985 would result in lesser exposure of this bug, but the patch gives a more logical behaviour for users with unthreads true.

David: is this patch waiting for something? (Let me know if you want it checked in.)

[Bienvenu (bienvenu)]

Thx, Magnus, I believe this can be checked in, and tried out.

[Mkmelin+mozilla (mkmelin+mozilla)]

I've checked this in for you.

Checking in mailnews/base/resources/content/threadPane.js;
/cvsroot/mozilla/mailnews/base/resources/content/threadPane.js,v <-- threadPane.js
new revision: 1.93; previous revision: 1.92
done

->FIXED. One less flag to look at:)

[Mcow (mcow)]

This part of the code before the patch's change:
   var dbview = GetDBView();
   if(dbview && !dbview.supportsThreading)
     return;
   dbview.viewFlags |= nsMsgViewFlagsType.kThreadedDisplay;

has a potential for failure: if dbview is null, the 'return' will be skipped and then the null pointer will be dereferenced. The if-clause should change to:
   if (!dbview || !dbview.supportsThreading)

Also, I notice the subsequent routine in the file, MsgSortThreadPane(), also references GetDBView() but doesn't check for null at all. If the test is unneeded, it should be removed; otherwise, it should be everywhere.

None of which is germane to this bug, which I just checked and can verify. :)

[Rolf Leggewie (r0lf)]

confirming since it is known to upstream, but don't hold your breath, initial report was about four years ago

[Gary-rumblingedge (gary-rumblingedge)]

Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.

[Øby (stian-oby)]

This has been "fixed" with this extension:
https://addons.mozilla.org/en-US/thunderbird/addon/5326

[John Vivirito (gnomefreak)]

This bug seems to be a duplicate of bug
https://bugzilla.mozilla.org/process_bug.cgi

[Justdave-mozilla (justdave-mozilla)]

John: not sure if you realized, but the link you pasted in comment 52 doesn't go to a bug. (and you only have to put the word "bug" followed by the bug number, Bugzilla will link it for you).

[Hskupin (hskupin)]

He meant bug 262319. I'm cc'ed there. Lets dupe the other one because we have more information here.

[Hskupin (hskupin)]

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

[John Vivirito (gnomefreak)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Øby wrote:
| This has been "fixed" with this extension:
| https://addons.mozilla.org/en-US/thunderbird/addon/5326
|
I commented on 2 upstream bugs that seemed to be dups of eachother since
i dont have rights to mark dups in mozilla's bugzilla. The extension
isnt a fix but a work around and was made exactly for this issue. They
seem to be flagging this bug for Thunderbird-3.0 for the time being.

- --
Sincerely Yours,
~ John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINPfkqig4QTwcPCoRAoXmAJ91btsjeia7sE0gV6lePXEfQ1ZMYACeO/jh
biYfHakb6/F2pGTvd9kfRdM=
=0n1z
-----END PGP SIGNATURE-----

[Wil Clouser (clouserw)]

The other bug was born out of this bug (see comment 36) - I'm not sure why it's considered a duplicate now.

[Hskupin (hskupin)]

Sorry, I missed that. I reopened bug 262319.

[John Vivirito (gnomefreak)]

Dave thanks for the information i wasnt sure if bugzilla did bug xxxx.
Do you have to have special access to mark bugs as dups and change status?
Henrik thanks for marking the dup.

[Mkmelin+mozilla (mkmelin+mozilla)]

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

[Eric Promislow (ericp)]

Fixed in Thunderbird 3.0b1? Seems to be.

[Rolf Leggewie (r0lf)]

Last comment in the upstream task seems to indicate this was fixed in 3.0b. John and Dennis, what is your status?

[Micah Gersten (micahg)]

Marking this Triaged as we have an upstream bug.

[Orion-cora (orion-cora)]

I don't think so. I'm still seeing the old behavior with 3.0.1 in Fedora.

[Bugzilla-mozilla-x (bugzilla-mozilla-x)]

After reading comment 26 pointing to Bug 166254 , I have understood that sorting by "Received" is giving same value as sorting by "order received", and it is working well moving threads on the top of the list when a new message on the thread is added.

So even if bug is not solved, it is a workaround. The problem is that this workaround was difficult to find.

[Alta88 (alta88)]

in fact, 'order received' is misleading. it really means 'offset into the mbx file', ie 'order added' and a moved/copied message will be 'last' regardless of date sent or date received.

[Klausg-k (klausg-k)]

Similar discussion:

bug 479969

https://bugzilla.mozilla.org/show_bug.cgi?id=479969

This is very old report. Not resolved till now.

[Ray Satiro (raysatiro)]

I'm not sure if I have the same problem but I'll explain it. Messages I received in Thunderbird did not actually have the right 'Received' date. So I added mailnews.customDBHeaders = " Received" and now the received column shows the date when my mail was actually received. But sorting by 'Received' is still no different from supporting by date. So I tried 'Order Received' and that seems to work except with threaded messages. For example ascending threaded:

foo 100
bar 102
-re:bar 105
qux 103

So I would expect that the 'bar' thread would come after qux but it doesn't. This is actually a big problem sometimes because I have a lot of messages in my inbox and sometimes when they don't arrive for several days they end up way back earlier in the list and I don't even notice them. I will upload two screenshots.

In fairness that happens rarely but I'm surprised this bug has been open for a decade. How do we get it handed off to someone?

[Ray Satiro (raysatiro)]

Created attachment 8811577
Date thread ordering.PNG

[Ray Satiro (raysatiro)]

Created attachment 8811578
Order received thread ordering.PNG

[Martin (martin22)]

Within a thread, being able to use the received date order instead of the default reply-to tree is indeed a major missing feature for my TB usage.

[Mozillabugz (mozillabugz)]

Not sure if I'm seeing the same bug, or a different one, for me it has started happening a month or two ago, affecting news but not mail.

I normally view sorted by order received, threaded, ascending
I quite frequently switch between all and unread messages

Using the menu/view/sort-by/order received, I see the "selected" indicator dot against "order received" and I see the "^" sort indicator in the order received column header of the message list pane.

If I then swap between unread and all messages using the dropdown in the toolbar, I see the "^" indicator moves to the date column header, at this point the menu/view/sort-by still shows the selected indicator dot next to the order received entry

But if I then navigate to a different group, and then switch back to the original group, there is no longer *any* indicator in the menu under view/sort-by and the sorting is messed up.

I can always reselect order received and it will sort properly until I alter the all/unread toggle and navigate between different groups, then the sort is broken again.

Running 45.6.0 on Win10 64 bit

[Quentin-dupont (quentin-dupont)]

Hello !
Still this problem in last version 91.3.2

thanks for all the work