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.

[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