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

Bug #115153 reported by Dennis S on 2007-05-17
10
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Confirmed
Wishlist
thunderbird (Ubuntu)
Wishlist
Mozilla Bugs

Bug Description

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

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.

In , Mcow (mcow) wrote :
Download full text (3.1 KiB)

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

Read more...

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

In , Mcow (mcow) wrote :

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.

In , Mcow (mcow) wrote :

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?

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

In , Mcow (mcow) wrote :

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

In , Mcow (mcow) wrote :

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.

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

Sounds like a duplicate of bug 262316.

In , Mcow (mcow) wrote :

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.

Exactly.

Gerv

In , Mcow (mcow) wrote :

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

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?

In , Mcow (mcow) wrote :

(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) wrote :

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

Dennis S (dennis-dennisschaaf) wrote :

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

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

Hi,

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

A/

Changed in thunderbird:
assignee: nobody → mozilla-bugs

FYI. Seamonkey version is Bug 389935.

26 comments hidden view all 106 comments

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

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

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

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

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

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

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

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

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

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

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

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

Alf (hubbuntu) wrote :

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

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

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/

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

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

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

In , Mcow (mcow) wrote :

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

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

Changed in thunderbird:
importance: Undecided → Wishlist
status: New → Confirmed
Changed in thunderbird:
status: Unknown → Confirmed

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

Øby (stian-oby) wrote :

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

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.

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

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

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.

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

Fixed in Thunderbird 3.0b1? Seems to be.

Rolf Leggewie (r0lf) wrote :

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

Marking this Triaged as we have an upstream bug.

Changed in thunderbird (Ubuntu):
status: Confirmed → Triaged

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

Changed in thunderbird:
importance: Unknown → Wishlist

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.

Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.