Open Bug 254159 Opened 20 years ago Updated 2 years ago

With Order Received sorting, order threads by date of last/latest message in thread

Categories

(Thunderbird :: Folder and Message Lists, enhancement)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: cross, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Date thread ordering.PNG
20.88 KB, image/png
Details
Order received thread ordering.PNG
21.04 KB, image/png
Details 
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.
Severity: normal → enhancement
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. ***
Summary: [RFE] Add a sort order/flag so that the last descendant of thread is used → sort threads by date of last/latest message
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.
Summary: sort threads by date of last/latest message → With Order Received sorting, order threads by date of last/latest message in thread
Version: unspecified → Trunk
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?
QA Contact: front-end
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.
Assignee: mscott → nobody
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/
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a1?
Moving from wanted‑thunderbird3.0a1? flag to wanted‑thunderbird3.0a2? flag since code for Thunderbird 3 Alpha 1 has been frozen.
Flags: wanted-thunderbird3.0a1? → wanted-thunderbird3.0a2?
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.
Flags: wanted-thunderbird3.0a2?
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.
See Also: → 1257826
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?

    
  
Component: Mail Window Front End → Folder and Message Lists

    
    

    
  
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
Flags: wanted-thunderbird3?

    
    

    
  
Hello !

Still this problem in last version 91.3.2


thanks for all the work



    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: