Both Apple's Mail client, and mutt (I think Mail does it by default, and I don't know if you can turn it off) have a way to sort by order-received, but have the *latest* descendant of a thread (when using threaded view) effect the sort, rather than the initial message in the thread. I would like Thunderbird (prob. also Mozilla MailNews) to have this feature. It could either be a flag, like threaded/unthreaded, or could be the default behaviour of "threaded". Probabaly better to have a flag, tho. Maybe a pref checkbox? "Use last message in thread for sorting" ? Then it would apply to date-sent, date-received, order-received, etc. Unclear what should happen when the sort is by subject or sender. Does that turn off threading anyway? I think maybe it does... Let me know if this is a dup (I looked and didn't see one like it), or if it should be MailNews instead of Thunderbird. Thanks.

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

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. :-)

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?

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

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.

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

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.

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. :-)

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

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

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.

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

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.

Resummarizing specifically for the Order Received case.

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

Any chance to have this in 2.0?

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

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.

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

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.

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.

Sweet, Will do.

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.

(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

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.

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.

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

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

Did last time I checked. The sorting is correct after resorting but when a new e-mail is received it breaks.

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.

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

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.

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.

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.

(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

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

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!

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?

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

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

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.

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.

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

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.

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.

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.

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.

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.

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/

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

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

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

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

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

Sorry, I missed that. I reopened bug 262319.

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.

Fixed in Thunderbird 3.0b1? Seems to be.

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

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.

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.

Similar discussion: bug 479969 https://bugzilla.mozilla.org/show_bug.cgi?id=479969 This is very old report. Not resolved till now.

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?

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.

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