This bug is still present 12 years later and it makes using Thunderbird a no-go for me. Why would I want this behavior when I sort by date descending?

I literally uninstalled Thunderbird right after setting it up because this bug frustrates me every time I try to move back.

Alessandro, Thomas,

Is this bug something you could help fix?

Indeed with large data set to handle, I confirm the annoyance caused by this bug... it is not something the brain muscle adjust to... it would make more sense to fix it... by allowing the threaded message to appear in descending order (most recent msg at the top).

I thought perhaps that is something you can help with... it would be handy for organisation users but also all TB users in general...

Regards,

Just to be clear, would this mean :
Rather than appending the new mail to the last thread in conversation as is done now, where the Date descending sort by is based on original email....
The newly received unread mail would become the new top level email that is sorted by Date Descending and it would contain all the older threads in date decending order. This would inevitably constantly change the positions of the threads. Also the new top level email will be displayed if threads are collapsed. Thus meaning people could instantly see and read new threaded emails without even expanding the thread. This would reduce number of clicks to locate email in a threaded environment and therefore increase work throughput for those handling a lot of emails.
I can this being a benefit.
Although I will admit, I've used the current system for so many decades it just shows my age, so muscle memory was adjusted long ago :)

However, what happens if you choose to 'Open message in conversation' in a tab?
Would those emails be displayed with oldest first, so you could actually read one after the other as if a conversation where the natural way of reading is top to bottom?

I don't mind what happens in the conversation view as long as it jumps to the opened message within the thread. At that point, I can navigate easily either way. I just want it to stop putting the oldest email at the top of the thread when the rest of my inbox works entirely the opposite way.

Not sure why I wasn't notified of @Anje's reply when they submitted it, but so it goes sometimes... To actually address it: @Anje, that's the whole point of the described view. That's how Gmail does "Conversations", and that's how many, many email users are accustomed to seeing their mail presented. They want to see a single thread of the whole tree. The whole tree itself need not appear together.

Looking back on this now, however, I have realised that there is perhaps a better term than "thread" to be used in this context; we're only interested in seeing the ancestors of a message. Thus, instead of "Threaded", maybe something more semantic like "With ancestors", or even "With ancestors (like Gmail)" would be preferred in the View preferences. Perhaps it is not sensible at all to show "Threaded" under "Date/Descending", instead only showing "Threaded" under "Date/Ascending"; and "With ancestors" under "Date/Descending".

Perhaps this different, specific terminology will make this feature request (or, indeed, the apparent bug seen by users who don't get what they expect when they choose "Date/Descending/Threaded") less controversial.

The logic of sorted threads being from oldest to newest no matter the sorting of the view it's kind of a standard, as that's the main purpose of a threaded view.

The problem lies more in the way we handle (wrongly) the UI when a thread is selected.
Right now it's kinda useless, as we list a bare overview of all the messages in the thread, so the user is forced to open the thread and scroll to the newly received message.

Other email clients are smarter in handling this, for example Gmail, by showing this sort of UI:

Quick preview of the first message

Collapsed block of messages (with number) that can be expanded with a click

Last message

That UI mitigates the "weirdness" of having the thread ordered differently, and improves the usability of the thread by keeping the focus on the last unread message, without forcing the user to needlessly scroll through all the previous messages.

We can definitely implement something like that.

(In reply to Alessandro Castellani [:aleca] from comment #42)

The logic of sorted threads being from oldest to newest no matter the sorting of the view it's kind of a standard, as that's the main purpose of a threaded view.

My main purpose for the threaded view is grouping together related emails to simplify browsing related messages (i.e. a conversation/threads of conversation). I don't see why reversing the sort order is an unreasonable request for that.

(In reply to Alessandro Castellani [:aleca] from comment #42)

The logic of sorted threads being from oldest to newest no matter the sorting of the view it's kind of a standard, as that's the main purpose of a threaded view.

The problem lies more in the way we handle (wrongly) the UI when a thread is selected.
Right now it's kinda useless, as we list a bare overview of all the messages in the thread, so the user is forced to open the thread and scroll to the newly received message.

Other email clients are smarter in handling this, for example Gmail, by showing this sort of UI:

---

Quick preview of the first message

Collapsed block of messages (with number) that can be expanded with a click

Last message

That UI mitigates the "weirdness" of having the thread ordered differently, and improves the usability of the thread by keeping the focus on the last unread message, without forcing the user to needlessly scroll through all the previous messages.

We can definitely implement something like that.

That sounds like a good workable idea. This bug was created by those who do not like to scroll to locate new threaded message as it consumes time. Especially as many people probably work with collapsed threads to make best use of space. Quick focus would resolve that problem.
This bug will have many comments from those seeking a better method of gaining focus or simply want to read in what I would call a weird direction, but those who are content with the current direction of threaded emails would not look for this bug nor would they comment, so there are voices out there who may feel the current display is perfectly ok as it is normal, but perhaps would agree that a quick focus would seriously improve work throughput.
Currently, the Quick Filter Bar already provides a quick sort for unread mail, but sometimes it is desirable to see more of the conversion.
'Open message in conversation' also provides the means to separate a converversion, unthread and sort by date, so putting newest at the top, so that view for a conversation is already possible, but it's not any quicker than scrolling in a threaded view in Thread Pane.

Alessandro, you have come up with a good workable solution which would resolve that inability to get quick focus. I'm in total agreement with you. It is a good way of moving forward.

I think it would be more complex to offer two separate methods of displaying the threaded emails and perhaps Alessandro's proposal would be quicker to implement.

Alessandro,

(In reply to Alessandro Castellani [:aleca] from comment #42)

The logic of sorted threads being from oldest to newest no matter the sorting of the view it's kind of a standard, as that's the main purpose of a threaded view.

Why can't Thunderbird lead by innovative on the matter? Has it been attempted?

It is not a standard... just something people may be accustomed to due to default settings in most email client but not necessarily the best option when message list is ordered in descending order...

I among those that list messages in descending order with threading enabled... this is a question of efficiency and the fact that you have to unfold the thread in the message list and browse all the way at the bottom to read the most recent message is a real annoyance/nuisance especially when the thread is quite long... this bug is related to the message list view and not the preview pane just to clarify from my understanding... try to give it a go yourself on a daily bases... you would quickly see what the issue is... I think you need to use it to understand it...

Would it be really that difficult to just provide a preference to reverse the order in a threaded conversation from newest to oldest if end-user want to especially if emails are ordered descending? Has it been attempted and tested? Would it be just a matter of creating each thread like now and just reverse each of them?

Both descending and threaded are not the default view option of TB so they would need to be already triggered by end-user to see the problem... most people would just keep the default TB settings likely by ignorance of the feature available so this issue may in theory affect only a minority of advanced users... but still an issue that require some solution... to improve performance... and reduce usage of brain muscle :-)

I should simply be able to see and access the last message receive within the thread without having to unfold the thread... that seems an evidence no?

An when it unfolded to have the most recently received messages received at the top of the list...

Other email clients are smarter in handling this, for example Gmail,

Compared to Thunderbird Gmail is really a bad UI/UX to manage emails especially in large quantity of them so it would be great if Thunderbird would not become a Gmail interface... can we not constantly copy Gmail when an issue raise in TB?

That said while I use Gmail, I am not familiar with the feature your refer to... is that something that needs to be enabled in Gmail? I am not fundamentally against the idea... but I don't think it would really answer this bug... but I am happy to test any solution you may have in mind and provide some feedback if that can help move forward...

Regards,

(In reply to Alessandro Castellani [:aleca] from comment #42)

Other email clients are smarter in handling this, for example Gmail, by showing this sort of UI:

---

Quick preview of the first message

Collapsed block of messages (with number) that can be expanded with a click

Last message

Is the attached picture what you are referring to, above?

First of all, this picture relate to the Gmail preview pane showing the conversation (in my case) and not the the message list which in Gmail does not allow to expend the threaded conversation of messages (in the message list) like TB allows... so that may be two different features...

I am not sure I would want TB to show list of message (in the message list view not the preview pane view) like Gmail does in its preview pane really not efficient nor convenient to use... but that is just one (my) opinion...

I really don't like the fact that in Gmail you cannot expand the threaded conversation within the message list... probably because I am used to that feature in TB already :-)

In threaded view, sorted by date descending, the oldest will be the one sorted by date.
All received conversations stemming from the oldest are in received order like a conversation, so newest at bottom appended to conversation.
I've always found this to be logical. I would not like to change this option, so it should remain as default.

Right click - Open message in conversation
Offers option to see full conversation with option to remove threading and sort by date preference, so newset can be at the top. Basically you get do whatever you want.

I among those that list messages in descending order with threading enabled... this is a question of efficiency and the fact that you have to unfold the thread in the message list and browse all the way at the bottom to read the most recent message is a real annoyance/nuisance especially when the thread is quite long...

Trying to locate new mail hidden in a thread - Work efficiently or smart as some say - be savvy - Use Quick Filter to show Unread only means you can remove all clutter and locate new mail instantly. There should never be a need to go hunting for a new mail even in threaded view. Use 'Unread' filter icon and make life easier.
Although I have improved the current underline of oldest message and replaced with blue text, so much easier to see which thread has new mail.

I'm not in favour of copying anything of Gmail feature. I can logon to webmail if I prefer gmail. But I feel people use Thunderbird because it offers something very different from the likes of Outlook and Gmail.

If you look at blogs, Facebook etc, I always see people's comments appended in the order received, so it is a natural method curently deployed.

I was under the impression this bug was specifically about completely changing the order.
So if sorted by Date descending then threads would behave the same.
So everytime you get a new message in ongoing threaded conversation, it becomes the new top level threaded email - sorted by date and all other previously received threaded emails are displayed appended to the new email with oldest/originating email at bottom. Basically a complete reverse of current situation.
Sounds more complicated with a constant reshuffle (perhaps indexing) of sort by date email and all threaded emails would also get reshuffled.
What problems are likely to arise as it may also need to extend into other sorts like Group by?

How would you describe this as options in the Sort by ?
Current Sort by date Descending does not apply to threaded where threaded is ascending.

Would Thunderbird need to then separate the options to offer the default classic view and also offer the reverse conversation view?
Example
Sort by Date, Descending, threaded ascending (current)
Sort by Date, Descending, threaded descending
Sort by Date, Ascending, threaded ascending (current)
Sort by Date, Ascending, threaded descending

It may sound easy to say just reverse it but would this end up being a rather time consuming task?

@Anje,

I guess implementing the second option from your list: Sort by Date, Descending, threaded descending would probably take care of filling the gap for all users from the "descending" camp.

As someone who's had to use at work, for years, other mail clients which offer natively a conversation/thread view that allows fully sorting ascending/descending and as a member of the "descending" camp, I guess I'm partially preconditioned (like many others).
Even though I've been using Thunderbird at home for many years more than 11 mailboxes, I still find it non-intuitive to scan my Thunderbird folders from top downwards but then "put my brain in reverse" each time I expand a thread to re-read some conversation.

Since the current "descending" sorting is still partially skewed in favor of the ascending sorting (i.e. inside threads), option # 2 would help bring some balance in choices. All while fulfilling a lack, for all those who aim to both use conversation threads and to have everything sorted descending (I'm "guilty" of that).

Conversely, from what I've seen in online posts so far, most people from the "ascending" camp seem to be pretty wholeheartedly on that bandwagon. So, I'm not sure how many users currently using an ascending folder view, would toggle the inside-thread sorting to descending (maybe some would if it were there).

Ultimately, I'll leave it to others to argue for or against the utility of option # 4, since I never use the ascending view in any mail client; I'm putting a vote up for option # 2 though.

Fourteen years, and still so fix for this simple yet fundamental issue?

Well, here's another reason this needs to be resolved. I'm trying to kick the Outlook habit, and that's how Outlook does it: days grouped with most recent day at top, messages sorted within each day with newest message at top of that day. If you want to wean people off corporate software, why not eliminate this barrier?

Of course, I understand that different users will have different preferences. Offering a good range of choices is exactly what makes software appeal to a broad range of users, and - I always thought - would be a big selling point of open source software versus commercial locked-in applications. And surely "newest day first/newest message first" would be one of the two most basic, obvious choices when it comes to sorting?

I suggest that what's really needed are two separate sort settings: one for sorting grouped days (or threads), and one for sorting messages within each group. Can this be so difficult to implement?

Being someone listing email in descending order, most recent email at the top, I can confirm it is reallty annoying not to be able to see and access the most recent email in conversation at the top when folded instead of the oldest one.

Also when unfolded I would like email from the conversation in descending order as well with most recent at the top and least recent at the botom... while keeping view of the conversation in reverse order basically...

It would also be helpful to have a stronger separation between last msg in conversation and the next one when conversation is unfolded... some sort of visual aid/separator that indicate clearly end of the conversation to facilitate reading/scanning of msg in the list...

On a separate note, ability to group messages/conversation per day would also be helpful and much welcome improvement.

Another bump. The update to 102 enabled threads on all instances in our department, and while I like threads, almost all of the workers got confused as to why they didn't see newer messages anymore: Threads were collapsed by default and showed only the oldest message, so any reply was hidden in the thread.

If the outer order is descending, the order within the thread should be descending as well.
If a thread is collapsed, a new message is even hidden with the order as it is right now.

(In reply to blastingagent from comment #51)

Another bump. The update to 102 enabled threads on all instances in our department, and while I like threads, almost all of the workers got confused as to why they didn't see newer messages anymore: Threads were collapsed by default and showed only the oldest message, so any reply was hidden in the thread.

If the outer order is descending, the order within the thread should be descending as well.
If a thread is collapsed, a new message is even hidden with the order as it is right now.

I noticed this issue as well in 106.x branch... threading shall not be enforced by default on all folders especially for those reading email in descending orders... not sure where that is coming from but seems to be quite an annoying bug... and will be for large organisation that would be affected by it...

If you want to enforce threading by default for all folders, please have this bug fixed first :-)

Thanks everyone for their inputs, and Richard L. for the ping.

TL;DR: If possible, it would be great if we could do something quick and dirty about the UX problem of this bug soonish before more users get affected now that threaded has become the new default and isn't easy enough to opt out of.

My personal UX feedback / user story:

• This bug is exactly what I found most inconvenient about the new threaded default, and although I can see the advantages of threaded, this shortcoming makes me often switch back to unthreaded just to be sure that I haven't missed any important new messages.

QA/UX analysis/input:

• This bug (RFE?) has gained new relevance now that Thunderbird has made threaded the new default mode by design (bug 1764842).
• Different users have different needs: Although threaded vs. unthreaded would appear to be a very important choice for users as it radically changes the presentation of and interaction with the message list, strangely there's nothing exposed in preferences to change this important setting (and the underlying pref isn't self-explaining: mailnews.default_view_flags = 0/1).
• ux-control, ux-consistency, ux-error-prevention: Affected users report that they are struggling with the new default, and the problem described in this bug makes it worse: Each closed thread will only show the oldest/original message of the thread. Newest messages are buried deep down at the end of the thread, and users need to open each thread and drill down to reach them (Keeping all threads open is possible, but massive clutter). This is of particular concern for (but not limited to) users which sort threads descending (newest first), because it's somewhat inconsistent then that inside threads, it's oldest first. So we have reports here of users missing out on new messages, which is the opposite of feeling in control, and Thunderbird should seek to prevent such errors.
• ux-discovery: Discovering how to get out of threaded mode isn't exactly trivial - that little Display message threads iconic column header is easy to miss, and doesn't indicate its state. New messages are also not easy to discover because of this bug.

UX recommendations/considerations (derived from QA/UX analysis):

• We should try to expose defaulting to threaded mode or not in the preferences UI (in a dedicated bug).
• If possible, and at least until something like Comment 42 materializes, we should try to find a quick and dirty fix for this bug, which involves being able to revert the order inside the threads. Unfortunately, my 2D mental image morphing skills aren't developed enough to imagine what a nested tree (especially those tree lines at the side) would look like when the tree is upside down, but I hope it's possible somehow without looking gross. Alex has hinted today that we could consider looking into a fast fix.
• For more flexibility, maybe the order inside the threads should be independent of the outside order (not sure, but others have mentioned this here). The fact you generally want newest threads on top may not necessarily imply that you're ready for thread trees upside down.
• While comment 42 is definitely useful UX, I doubt if it would fully solve this bug. This bug seems to be about efficient presentation and navigation between messages in the message list, not in the thread preview in message reader. In particular, I'm thinking about super-efficient cursor-key navigation in and out of threads in message list. Iiuc, comment 42 alone would require to constantly switch between message list and message preview pane, which may or may not work well for mouse users, but may constitute a significant inefficiency for keyboard users.

Implementation hints

• I have no idea how hard it would be to teach the current tree to display thread sub-trees (including tree-lines?) upside down, but I guess that's what we're after for a fast fix.

This is the pref which changes threaded vs. unthreaded default for any new folders or new accounts (implemented by bug 1764842). This will be most effective if you change the pref before setting up your accounts in a new installation.

mailnews.default_view_flags = 0/1
0 -> default to unthreaded
1 (default) -> default to threaded

Note, changing the pref will not change the threaded setting for any existing folders.
You either need to change those one by one, or you can use Apply current view to... from column picker on the far right edge of the message list column headers. This will also apply the other settings from View > Sort by like which field to sort by, and Ascending/Descending.

It's worth noting that threads can be nested and thus not in chronological order e.g. when a message from the middle of the thread gets directly replied-to last. Which means that the latest message will not always be at the bottom of the thread. Which probably means that even if we turn the thread upside down, the latest response may not always be at the very top. I think.

(In reply to Thomas D. (:thomas8) from comment #55)

It's worth noting that threads can be nested and thus not in chronological order e.g. when a message from the middle of the thread gets directly replied-to last. Which means that the latest message will not always be at the bottom of the thread. Which probably means that even if we turn the thread upside down, the latest response may not always be at the very top. I think.

You are spot on. There is a very good reason why the threads are in conversation order. It gets worse if there are actual more than one response in various sub trees. The reason we have the current design is because it allows for an expanding conversation from the root.

Providing I can still use this in a normal fashion - Date - Descending -Threaded and all my threads have old at top, so they appear in correct converstion flow; I'm good.

People may ask for this but it does not mean it is do-able.
Perhaps those who ask only experience a single tier of conversation or do not know they can choose to flip to display unread and later flip back to threaded. They are not using the tools already available.

When there is one email which is the source of all conversation, it is obvious which the one is used in the sort start.
When a conversation has expanded like an ancestral tree and you desire to completely invert it, it means all the unread children must display first, so the threads will become broken - it defeats the purpose of threading.

If this bug is worked on, it should be a completely new style and not interfere with any current design options.
It is not going to be a proper threaded option as that is impossible.

The problem seems to be 'locating' new unread mail because perhaps the threads are collapsed or it is not immediately obvious which one has the new mail - that is not the same as inverting all the threads.
Currently, the collapsed thread becomes underlined. There is no 'new mail icon' on the collapsed thread.
I ended up using 'userChrome.css' to force the top thread to be in blue if it contained a new mail just to draw my attention.

Idea - what would people think if all threads with new mail were auto expanded, so it would immediately draw attention to new mail as they would be :

• immediately visible
• have bold text
• have unread icon
• have new mail icon

How quick or easy would it be to implement that auto expand if contains new mail?
Or provide a preference/menu option to switch that 'auto expand if new mail' option on.
then wait for feedback to see how this helps to improve easier to locate.

(In reply to Anje from comment #56)
I indeed usually only have linear conversations and always had (before the update that forced the option) threads disabled, so the problem of tree-like conversations when trying to reverse thread-order never occurred to me.
Since, as you said, my main issue is that new mails are buried inside threads, especially if one's not used to how threads are rendered, how about the following:

The idea behind using the chronologically first mail as the thread root is that all other mails, regardless if linear or tree-like, are necessarily descendants of that mail, and thereby its subject is sensible as a base-subject for the thread.
Let's say the thread is collapsed and there's a new reply. Now, the thread root could become bold and unread, since the thread contains an unread mail, and its date could be changed to the date of the most-recent new mail in the thread. Since the root-mail's subject can be considered as base-subject, this can be interpreted as there being a new mail with said date under that subject, not as the root-mail having a new date or being unread itself.
When the thread is expanded, the root mail regains its original date and read-state, since the unread mail is then visible. This would also at the latest clear up any doubts on the root-mail itself being unread.
After collapsing the thread again, the root-mail would retain the date of the most recent mail within the thread, as that's the date the subject was last touched upon and since it justifies the position of the collapsed thread within the other mails (I'd expect a thread containing a new mail at the top in descended view, not wherever the root-mail resides because of its date).

That way, new mails are as visible as they are in the unthreaded view just like with your proposed auto-expansion, with the added benefit of being more orderly and thread-like, which might be more accustomed to long-time users of threads.
Otherwise, users who frequently receive mail in threads to which they normally don't reply immediately would maybe have to fight re-expanding threads in which they are not interested.

Another possibility I'd see is to only expand the unread mails of the thread. This would improve on the root-mail having other properties in collapsed-state than it actually has (visible in expanded state) and deeply nested threads wouldn't repeatedly consume a lot of space when new mails arrive until the thread is collapsed again, but only as much as the number of new mails within the thread.

I'd prefer the first approach since that corresponds with what I'd intuitively expect from a thread, but I'm interested to hear other expectations!

I think this bug reveal multiple issues here:

• Enabling of threading for all folders by default in Mail Space > Message List

** This should be the case only after all threading issues have been resolved, currently there are not, so a revert to legacy default settings (no Threading by default for all folders) would be advisable in the shorterm. Keeping current end-user per folder customisation.
** Threading by default could be postponed to after the revamped of the message list UI/UX currently in tbe pipeline during which threading issues could be fixed.
** On a general note, TB dev teams shall not change default settings or user settings of existing user profiles without informing users during upgrade process and providing opt-out option on spot and explanations to change settings (enable/disable) later on... don't force and push defat option to users. New profile perhaps but not existing user base..

• Threading issues

** With message list in descending order (newest at the top to oldest at the bottom), with Threading enabled, and conversation folded: the conversation is correctly listed at the right date in msg list, based on last msg received within conversation, but display the oldest message header info often as read (root msg).
Ideally:
*** it should dislay the last msg received info instead which would appear unread.
*** it should display how many unread msg are available in conversation if more than one have been received.

** With message list in descending order (newest at the top to oldest at the bottom), with Threading enabled, and conversation unfolded: root message appears at the top with conversation msg in ascennding order (mostly) except some replies that may be burried in tbe middle (as noted by Thomas). This is expected as per conversation current feature...
Ideally:
*** the end of conversation should be clearly defined with proper separation (eg line) from next msg/conversation in msg list. Currently very difficult to distinguish.
*** The last up-to-date msg received should be highlighted maybe with a light background color different from msg list background color. This way you could quickly and easily identify the leaf message in tbe convetsation especially if multiple unread msg were received in the conversation.
*** For those that want it should also be possible to see the conversation in reverse order. I know it may seems strange to developers but yes that would be handy to access most recent message received at the top. In a similar way some end-users prefer msg list in desending order (most recent msg at tbe top). I know that some people try to keep the convention of conversation in ascending order as it is if usage on the Internet, but Tbunderbird could be thinking outside tbe box and be more inovative. Anje mentioned workarounds but that is not the point nor what is needed or wanted. Anje mentioned technical difficulties, there are not to be denied, but to the extend of saying it is not feasible, I clearly doubt so. If you can classify assending list of messages in ascendfing order into conversation you certainly can do so in descending order, with conversation in descending order. But as Thomas indicated the order inside the threads should be independent of the outside order (aka order of msg/folded conversation list). This could be explored and tested within the project of revamping msg list UI/UX.

I believe that most of the arguments against the possibility / usefulness / meaningfulness of implementing the option of descending order inside threads (when it's selected for the folder) are stemming from the current way TB is displaying threads, namely in the form of an upside-down tree with branches going rightwards, and based only on the "in-reply-to" parent mail, with complete disregard of the dates.

Which makes the thread useful if you want to know which mail is in reply to which but a rather unholy mess when it comes to easily understanding in which order they came:

Current thread ordering:

|_ root                      (Sep 1st)
|
|_ replroot1                 (Sep 2nd)
|   |
|   |_ repl1-replroot1       (Sep 5th)
|   |
|   |_ repl2-replroot1       (Sep 6th)
|
|_ replroot2                 (Sep 3rd)

Yet didn't Git solve this, ages ago, in their CLI graph representation of commits?
This type of thread ordering would allow for showing both the tree and sorting ascending/descending by date of arrival.

Git-style thread ordering (ascending):

    >     root               (Sep 1st)
    |
 _  >     replroot1          (Sep 2nd)
|   |
|   >     replroot2          (Sep 3rd)
|
>         repl1-replroot1    (Sep 5th)
|
>         repl2-replroot1    (Sep 6th)

Git-style thread ordering (descending)

>         repl2-replroot1    (Sep 6th)
|
>         repl1-replroot1    (Sep 5th)
|
|   >     replroot2          (Sep 3rd)
|   |
|_  >     replroot1          (Sep 2nd)
    |
    >     root               (Sep 1st)

This approach could handle as many levels of branching and sub-branching as needed, just as Git does, and insure that mails within a thread are displayed in chronological order, irrespective of the sorting order chosen by the user (ascending or descending).

I suspect this may have been considered at some point during the long development track of Thunderbird but not embraced for some reason.
It would be interesting to know if it's because the workload to adopt it would be too high or for other considerations and if current arguments against such an approach still exist within the TB dev community.

A maybe better visual indication of how this could look is this image.

Any reasonable arguments against why this could not be chosen as path of development for a future version?

(In reply to adrmusina from comment #59)

I use Date > Descending > threaded and I see the following in the Thread Pane
root has newest main at top
replies in date order received in relation to root, so appended to list - bottom.
The diagram below is as it currently appears in thread pane.
In collapsed state only root1 (Sep 1st) and root2 (Aug 1st) visible.

    >     root 1              (Sep 1st)
      |>     repl1-root1        (Sep 2nd)  -
      |       |>         repl1-repl1-root1   (Sep 5th)  
      |            |>         repl1-repl1-repl1-root1  (Sep 5th)  
      |            |>         repl2-repl1-repl1-root1  (Sep 8th)  
      |       |>         repl2-repl1-root1   (Sep 6th)                      
      |>     repl2- root1        (Sep 3rd)  
      |       |>         repl1-repl2- root1    (Sep 4th)   
      |       |>         repl2-repl2- root1   (Sep 8th)   
    >     root  2            (Aug 1st)

Git-style thread ordering (descending)

>         repl2-repl1-root1    (Sep 6th)
|
>         repl1-repl1-root1    (Sep 5th) -  and what if you get replies to repl1-repl1-root1  on the 5th and 8th Sept
|
|   >     repl2-root1           (Sep 3rd)  - and what if you get replies to repl2-root1   on the 4th and 8th Sept
|   |
|_  >    repl1-root1           (Sep 2nd)
    |
    >     root 1             (Sep 1st)
    >     root  2            (Aug 1st)

But how would this Git-style visually appear in the Thread Pane for the user.
The above diagram would not appear like that in the Thread Pane.
Please help by showing diagram as it would display in thread Pane and if you could also add in the additional replies I mentioned it would be helpful.

The design has to assume that any email within a thread can have replies and they are not necessarilly in date order. One part of a thread can have dates overlapping another part of the thread, which breaks the threading if everything is put into date order.

In collapsed thread format - it looks like every time a new mail is received in a thread the entire thread will get reshuffled, previously received new mail still unread will suddently disappear from immediate view.
So if repl1-repl1-root1 (Sep 5th) is unread and visible and I have not got to it as yet and then a new mail arrives:
repl2-repl1-root1 (Sep 6th) in this example is now newest, so will be the visible item in a collapsed thread - it replaces the root or whatever was previously visible which in this senario repl1-repl1-root1 (Sep 5th) unread is suddenly gone from list.

I'm not so sure I want emails to keep disappearing from view as I'm workng through list - it's rather disconcerting and you still would not know if there are more than one unread in a thread. You would still need to expand and drill down.

This topic has a problem in locating email, it fails because people cannot easily and quickly locate mail within a thread. The threading method and locating mail problem are not one and the same, but offering a better method to easily locate would go a long way to improving the current options. The underline does not draw attention and can look messy if people use a compact view. It does not indicate new mail.

If no auto expanding or user chooses collapse thread:

• Root level mail needs to be more obvious that it contains new mail or unread mail.

If thread is collapsed and contains new mail or unread mail:

• Root mail Subject font needs to be bold
  I also suggest you make better use of the 'thread' column icon.
  If thread has new mail:
• the root mail needs to have a 'new mail icon' on the 'thread' icon
• The thread icon could also turn green - same as the unread to indicate unread mail in thread pane because whilst new mail is unread, not all unread are new.

If the thread is auto expanded then it's thread contents will need full expansion to include expanding any subthreads, but then all the usual bold font, unread mail green dot, new mail icon get auto displayed on relevant email.

I would think it is a lot easier and quicker to get that 'indication' method implemented on the current situation to improve the ability to notice which thread has new mail or unread mail.

As the idea to enhance the indication of new mail and unread mail which is in a thread is not the same as the title of this bug, I have created a new bug 1792311 to discuss that particular aspect.

(In reply to Anje from comment #60)

I use Date > Descending > threaded and I see the following in the Thread Pane
root has newest main at top

Did you mean "newest mail at top"?
Because that's not what I see in my Thunderbird on an expanded thread (neither before nor after upgrade to 102.3.0).
Currently, for me it's oldest mail at top (as root of thread) which your depiction below shows as well.

    >     root 1              (Sep 1st)
      |>     repl1-root1        (Sep 2nd)  -
      |       |>         repl1-repl1-root1   (Sep 5th)  
      |            |>         repl1-repl1-repl1-root1  (Sep 5th)  
      |            |>         repl2-repl1-repl1-root1  (Sep 8th)  
      |       |>         repl2-repl1-root1   (Sep 6th)                      
      |>     repl2- root1        (Sep 3rd)  
      |       |>         repl1-repl2- root1    (Sep 4th)   
      |       |>         repl2-repl2- root1   (Sep 8th)   
    >     root  2            (Aug 1st)

Git-style thread ordering (descending)

>         repl2-repl1-root1    (Sep 6th)
|
>         repl1-repl1-root1    (Sep 5th) -  and what if you get replies to repl1-repl1-root1  on the 5th and 8th Sept
|
|   >     repl2-root1           (Sep 3rd)  - and what if you get replies to repl2-root1   on the 4th and 8th Sept
|   |
|_  >    repl1-root1           (Sep 2nd)
    |
    >     root 1             (Sep 1st)
    >     root  2            (Aug 1st)

But how would this Git-style visually appear in the Thread Pane for the user.
The above diagram would not appear like that in the Thread Pane.
Please help by showing diagram as it would display in thread Pane and if you could also add in the additional replies I mentioned it would be helpful.

You are correct, the true Git-style depiction of your thread tree above, would not look like the second one you modeled above.

Also, in my previous post I've showed a "Git-style" tree, branching leftwards, as I was just borrowing their concept of order by date and indicate mail by a symbol found at each line only on one of the branches not trying to mimic it 100%.

However, real Git graphs (in CLI):

• branch rightwards (which is the same direction Thunderbird branches currently);
• indicate the current commit (which in TB would be a mail instead) by an asterisk found only on one of the branches, per each line.

Please note that Markdown is a bit more limiting than what an UI designer would have at their disposal in terms of accurately indicating points of origin for branches or for pointing out the "current" mail on each line so the following are my best approximation with the tools at hand.

ASSUMPTION: Since the 2 mails received on 8th of September are on different branches and you didn't specify an arrival hour, I just assumed that repl2-repl2-root1 arrived last. But the tree would still work just as well (only look different) had they arrived in reverse order.

Your thread tree would look like below in "truer" Git-style (I'll use characters closer to Git as it's a bit easier for me to model the tree).

  *           repl2-repl2-root1                  (Sep 8th)
  |
  |   *            repl2-repl1-repl1-root1       (Sep 8th)
  |   |
  | * |        repl2-repl1-root1                 (Sep 6th)
  | | |
  | | *            repl1-repl1-repl1-root1       (Sep 5th)
  | |/
  | *           repl1-repl1-root1                (Sep 5th)
  | |
  * |           repl1-repl2-root1                (Sep 4th)
 /  |
*  /         repl2-root1                         (Sep 3rd)
|/
*            repl1-root1                         (Sep 2nd)
|
*        root1                                   (Sep 1st)

Same Git tree as above but trying to use in Markdown horizontal lines for branching, instead of the traditional Git, oblique slashes:

  *           repl2-repl2-root1               (Sep 8th)
  |
  |   *           repl2-repl1-repl1-root1     (Sep 8th)
  |   |
  | * |       repl2-repl1-root1               (Sep 6th)
  | | |
  | | *          repl1-repl1-repl1-root1      (Sep 5th)
  | |_|
  | *         repl1-repl1-root1               (Sep 5th)
  | |
  * |         repl1-repl2-root1               (Sep 4th)
 _| |
*   |       repl2-root1                       (Sep 3rd)
|___|
*           repl1-root1                       (Sep 2nd)
|
*           root1                             (Sep 1st)

As you can see, each branch dynamically "grows" all they way up to its own latest email, and the branch with the most-recent item is always the tallest.
Then, as soon as a newer email is received on any particular branch, that branch would just grow to be the "tallest" in the tree (until an even newer mail arrives later, then the process repeats).

Basically each new mail arrival inside the thread, would trigger:

• either a new branching followed by the growth of this new branch to become the tallest;
• or the growth of an existing branch to become the tallest.

For instance, let's say a 3rd reply repl3-root1to the original root1 mail arrives, on the 9th of September, then the original branch would grow highest and the previous tree would become:

*           repl3-root1                        (Sep 9th)
|
| *           repl2-repl2-root1                (Sep 8th)
| |
| |   *           repl2-repl1-repl1-root1      (Sep 8th)
| |   |
| | * |       repl2-repl1-root1                (Sep 6th)
| | | |
| | | *           repl1-repl1-repl1-root1      (Sep 5th)
| | |/
| | *          repl1-repl1-root1               (Sep 5th)
| | |
| * |          repl1-repl2-root1               (Sep 4th)
|/ /
* /         repl2-root1                        (Sep 3rd)
|/
*           repl1-root1                        (Sep 2nd)
|
*           root1                              (Sep 1st)

If after that on the 10th of September another reply arrives to repl1-root1 (on 3rd branch), now this branch grows tallest and the tree becomes:

    *          repl3-repl1-root1               (Sep 10th)
    |
*   |      repl3-root1                        (Sep 9th)
|   |
| * |         repl2-repl2-root1                (Sep 8th)
| | |
| | | *           repl2-repl1-repl1-root1      (Sep 8th)
| | | |
| | * |       repl2-repl1-root1                (Sep 6th)
| | | |
| | | *            repl1-repl1-repl1-root1      (Sep 5th)
| | |/
| | *          repl1-repl1-root1               (Sep 5th)
| | |
| * |          repl1-repl2-root1               (Sep 4th)
|/  /
*  /        repl2-root1                        (Sep 3rd)
|/
*           repl1-root1                        (Sep 2nd)
|
*           root1                              (Sep 1st)

I'm not inventing anything new here; all credit goes to the Git author (Linus Torvalds and anyone else who may have contributed on that code).

The design has to assume that any email within a thread can have replies and they are not necessarilly in date order. One part of a thread can have dates overlapping another part of the thread, which breaks the threading if everything is put into date order.

I believe that, as showed above, both ordering by date and indicating the branch can happily coexist. Unless I'm misunderstanding what you're referring to, here.

In collapsed thread format - it looks like every time a new mail is received in a thread the entire thread will get reshuffled, previously received new mail still unread will suddently disappear from immediate view.
So if repl1-repl1-root1 (Sep 5th) is unread and visible and I have not got to it as yet and then a new mail arrives:
repl2-repl1-root1 (Sep 6th) in this example is now newest, so will be the visible item in a collapsed thread - it replaces the root or whatever was previously visible which in this senario repl1-repl1-root1 (Sep 5th) unread is suddenly gone from list.

I'm not so sure I want emails to keep disappearing from view as I'm workng through list - it's rather disconcerting and you still would not know if there are more than one unread in a thread. You would still need to expand and drill down.

I'm not sure what you're referring to here, unless your Thunderbird behaves differently than mine.
TB's current behavior, in my case, for a collapsed thread, is that it displays:

1. the subject of the original mail and
2. the date/hour of the same original mail.

The only indication I have that there are new mails in the thread, is that the original mail is underlined (which is hardly visible).

If I select a collapsed thread, then I see in the reading-pane a chronological summary of its contents with: sender and date and body or only an ellipsis "..." as soon as the mail is a bit longer than a couple of sentences.
I don't see any reason why the same thing couldn't be displayed for a Git-style thread (which inherently is date-ordered anyway).

Or are you referring to how TB might behave if we did implement the Git-style tree?

If that be the case then I guess it's worth nothing that:

1. In 99% of the cases, the users who reply/forward an email back to us, won't alter the subject; therefore you end up with a new mail with a "RE:" or "FW:" prefix prepended to the original subject and a newer timestamp, in the mails list pane.
2. If from the whole thread you can see only 1 line, the most useful indication regarding arrival of a newer mail, would be its date/time anyway.
3. In that context I assume it can be only beneficial to see the timestamp of the latest reply on a collapsed thread, instead of the old original's or some "intermediary" reply's timestamp. If let's say 3 different replies arrived in the past 2 days, can you think of any circumstance where it would be more useful to see the timestamp of one of the earlier unread replies, on the collapsed thread?
4. Finally, let's assume that in some cases someone does alter the subject of a mail before replying/forwarding back to us. Arguably, I still see it more useful to show on the collapsed thread the subject of the latest unread mail, rather then the original's. But that's just a preference, in the end I don't care that much and maybe there are scenarios I hadn't thought about, where the other choice makes more sense.

At any rate, my original proposal in the previous post, was aiming mainly to address the current counterintuitive and clunky ordering of the mails in expanded thread-trees.
It didn't make any assumptions/suggestions regarding which method of updating a collapsed thread was better.

A date-ordered display of the thread itself, that automatically aligns with the ascending/descending sorting setting which the user has chosen for the mail list pane, would be more consistent and easier to follow.
Especially in a thread with multiple unread mails, in several sub-branches; currently, it's a headache to figure out in which order they arrived.

On top of that, the formatting choices that make more sense, can be added.

The underline does not draw attention and can look messy if people use a compact view. It does not indicate new mail.

If no auto expanding or user chooses collapse thread:

• Root level mail needs to be more obvious that it contains new mail or unread mail.

If thread is collapsed and contains new mail or unread mail:

• Root mail Subject font needs to be bold

I couldn't agree more with this one. In fact modifying the CSS to show threads with new mails as bold instead of underlined, is one of the first things I did in TB. Should this be added as a new TB setting, it would be a more flexible approach than forcing everyone into the current underline.

I also suggest you make better use of the 'thread' column icon.
If thread has new mail:

• the root mail needs to have a 'new mail icon' on the 'thread' icon
• The thread icon could also turn green - same as the unread to indicate unread mail in thread pane because whilst new mail is unread, not all unread are new.

If the thread is auto expanded then it's thread contents will need full expansion to include expanding any subthreads, but then all the usual bold font, unread mail green dot, new mail icon get auto displayed on relevant email.

I would think it is a lot easier and quicker to get that 'indication' method implemented on the current situation to improve the ability to notice which thread has new mail or unread mail.

I like these additional formatting suggestions above; I can see that in v102 TB already added more color to some areas/elements of the UI, which at least for some of us is a happy departure from the minimalist black & white, bleak style of late (I know others may disagree but I'm rather fed up with this all-white, hospital-like style which infused GUIs in the past few years).

I won't speak to how easy or hard it would be to implement the Git-style thread-tree suggested above, as I have to idea.
But if the devs would consider implementing it, since the Git source code is open source , maybe the part which generates the version-trees when we run something like git log --all --decorate --oneline --graph could be used as starting point.
And Thunderbird would not have to implement the whole logic, as it'd never have to handle merging; only branching out.

I'm still not convinced that it would work.
If thread is collapsed, the last new unread thread will disappear from view when a reply to it is received, so if you have not read the first email and you select the reply email now at top, - after all how would you know there was a difference - they have the same subject - you are ineffect reading the answer before knowing what the question was in the first place. You would still need to expand and check for any unread previous emails, so you do not misunderstand the last email which is now dispalyed first. It seems to be creating a different kind of problem.

I suppose it's down to preference.
For any conversation or reading a book - I read left to right and down. So for me it is highly illogical to read in reverse. As a conversation expands I like emails appended below. That's where I expect to locate the email. If I need to re-read some comments prior to latest email, then the process of reading downwards is natural.

I just would prefer the indication of which thread has new and unread mail to be improved, I'm happy with the current options but not happy with the ease of seeing which thread has new or unread mail. So we have a common problem in some aspects.
Maybe both the new/unread thread improvement and the reverse threading will get implemented.

(In reply to Anje from comment #63)

I'm still not convinced that it would work.
If thread is collapsed, the last new unread thread will disappear from view when a reply to it is received, so if you have not read the first email and you select the reply email now at top, - after all how would you know there was a difference - they have the same subject - you are ineffect reading the answer before knowing what the question was in the first place.

You are already suffering from that right now; the current version of TB offers no indication of how many unread replies are in a thread.
And the subject is the same currently, always, no matter how many newer replies you have in the thread. Namely, it's always the subject of the original mail.
So, it looks to me that you're complaining more about the current situation.

You would still need to expand and check for any unread previous emails, so you do not misunderstand the last email which is now dispalyed first. It seems to be creating a different kind of problem.
This the case today as well.

For any conversation or reading a book - I read left to right and down. So for me it is highly illogical to read in reverse. As a conversation expands I like emails appended below.

That's what my proposal aims to fix. Today you don't get mails appended at the end of the thread. They get appended to the immediate parent, to which they are a reply.

The ascending or descending order, as you say, is a matter of personal preference for everybody.
With the thread-tree I'm proposing that would be as simple as sorting the thread descending or ascending. Currently, any of these two is an impossibility.

I just would prefer the indication of which thread has new and unread mail to be improved, I'm happy with the current options but not happy with the ease of seeing which thread has new or unread mail.

The improvement to show in bold the threads with unread mails is possible even now, with a few lines of custom CSS in userChrome.css, it's just not a default or at least an option available via UI; it would be nice to have it.
But an even better option would be maybe, to have the tread bold AND somehow showing the number unread replies; this would address a bit what you said above, about not knowing how many new replies arrived, without expanding the thread.

In my personal experience, I never reply to a thread where I see I have new mails without expanding it so, for me that is a non-issue it but other people may have other working habits so, as you say for them this may be an issue.

Anyway, this discussion deviated a bit towards the related but not the same subject of visual formatting/cues to indicate new replies in a collapsed thread and how best to achieve that.

While I admit those are important points, my proposal deals mainly with fixing the fact that currently it's impossible to sort a thread in either ascending or descending order, fully.
I don't know if this will implemented or not, but it's my biggest pet peeve to an otherwise perfect (to me) mail client.

(In reply to adrmusina from comment #64)

(In reply to Anje from comment #63)

I'm still not convinced that it would work.
If thread is collapsed, the last new unread thread will disappear from view when a reply to it is received, so if you have not read the first email and you select the reply email now at top, - after all how would you know there was a difference - they have the same subject - you are ineffect reading the answer before knowing what the question was in the first place.

You are already suffering from that right now; the current version of TB offers no indication of how many unread replies are in a thread.
And the subject is the same currently, always, no matter how many newer replies you have in the thread. Namely, it's always the subject of the original mail.
So, it looks to me that you're complaining more about the current situation.

I'm not suffering from that situation. it's impossible because the new email is not displayed on a collapsed thread. The original root email is displayed.
I expand thread and immediately see the new emails appended in the order a person would read if reading left to right and down.

Perhaps I've misunderstood your proposal. Perhaps it will still initially sort on the original root email and all threads therein are still hidden which is really the same in that respect.

You would still need to expand and check for any unread previous emails, so you do not misunderstand the last email which is now dispalyed first. It seems to be creating a different kind of problem.
This the case today as well.

For any conversation or reading a book - I read left to right and down. So for me it is highly illogical to read in reverse. As a conversation expands I like emails appended below.

That's what my proposal aims to fix. Today you don't get mails appended at the end of the thread. They get appended to the immediate parent, to which they are a reply.

Agree, they get appended because it may occur one initial email gets sub threads as people refer to separate sections of the original, so at the moment the emails get appended to the correct sub section.

The ascending or descending order, as you say, is a matter of personal preference for everybody.
With the thread-tree I'm proposing that would be as simple as sorting the thread descending or ascending. Currently, any of these two is an impossibility.

I agree, it sounds ok and would work very well providing the conversation is purley linear but if there is subthreading then it ignores it and that may not be helpful.

I always assumed the Ascending and Descending order related specifically to the root/initial email sort and not any threads therein.
So the threads would be in conversation order and relate specifically to any subsection, so you can see immediately which sub section they are discussing. If the sub threading is removed then threading fails.

(In reply to Anje from comment #65)

I'm not suffering from that situation. it's impossible because the new email is not displayed on a collapsed thread. The original root email is displayed.

What I meant was that even today you're not seeing the more recent mails on a collapsed thread (the ones which you were afraid would disappear when newer replies arrive, in one of the previous posts).
So you can't possibly use the argument of losing something that isn't implemented even today. According to your own admission, you have to expand a thread to figure out how many new replies arrived, so allowing for a different tree graph and sorting method cannot interfere with that.

Anyway, as I said before, this is a completely unrelated design choice as compared to the thread tree graph and sorting order. The devs could choose to display whatever they want on a collapsed thread with new replies inside, irrespective of how the thread looks when it's expanded or what sorting it uses.
So we shouldn't conflate the two; I guess that particular discussion is better suited for the other bug you created, which concerns these very ornaments/decorations or visual cues on collapsed threads.
But as a personal choice, on a collapsed thread that may have started a year back, I'd still prefer to see the timestamp of the most recent reply than the original's, 1 year old, that we see today. Maybe I'm wrong or missing something.

I expand thread and immediately see the new emails appended in the order a person would read if reading left to right and down.

The left-to-right-and-down comparison doesn't really apply as a paradigm to multi-column lists, tables or databases.
Else none of these objects would ever have gotten sorting mechanisms implemented for them and the only choice in the IT world until today, would have been "ascending sorting". And the mail list pane is a table, in that sense; it has columns and rows.
By this logic even the descending sorting option for the mail list pane should be eliminated because it doesn't conform to the left-to-right-and-down paradigm.

However, your statement above inherently means you're partial to the ascending sorting order, which it totally fine.
Many of us aren't. Simply because we prefer not having to scroll all the way down to get to the newest mails. I'm sure both preferences have their merits and Thunderbird happily caters to both tastes currently, at mail list pane level.
The gist of this bug is that we'd just like the same freedom of choice inside the tread (those of us partial to descending order, that is).
This way, those who like ascending order (like you seem to do) would still retain what they like untouched, while the rest of us wouldn't be forced to switch our brain in "reverse-mode" every time we expand a thread.

Perhaps I've misunderstood your proposal. Perhaps it will still initially sort on the original root email and all threads therein are still hidden which is really the same in that respect.

I don't know if you had or not; my proposal has nothing to do with the ascending/descending sorting outside threads, but inside the thread.

Agree, they get appended because it may occur one initial email gets sub threads as people refer to separate sections of the original, so at the moment the emails get appended to the correct sub section.

On this we seem to disagree. You can call it the "correct" sub-section only if we really don't care in which order replies arrived and if we all prefer ascending sorting, which current threads partially implement.
Some of us though, do care about sorting order inside threads, as this bug is proof.

I agree, it sounds ok and would work very well providing the conversation is purley linear but if there is subthreading then it ignores it and that may not be helpful.

I disagree with this last statement; review again the trees I've modeled above; you can clearly see the parent of each reply so, yes, Git-style trees can handle infinite branching, and allow us to easily trace back each reply to its parent. It may happen that not everyone would like such tree graphs, just because some people got used to how things are now.
It doesn't mean the current situation is somehow better.
As proof, you have all the people who complain about the same thing, in this bug. :)

I always assumed the Ascending and Descending order related specifically to the root/initial email sort and not any threads therein.

It's true; that's the only thing they do today. And it's what this bug is aiming to change, in order to offer sorting choices inside the thread as well.

So the threads would be in conversation order and relate specifically to any subsection, so you can see immediately which sub section they are discussing. If the sub threading is removed then threading fails.

Threads aren't in conversation order today, they're grouped by sub-tree parents, which isn't really any order.
Then, inside any of the sub-trees, you're stuck with the default ascending order.
While I understand you may like the current setup, it is far from perfect and as this bug is proof, it doesn't serve everyone's needs.

I'd much prefer to be able to distinguish the order in which replies arrived inside a thread and to clearly see their parents, than to see them tucked away in "sub-sections" without any regard to timestamps, like today.
A Git-style tree does indicates parents clearly enough, therefore you can immediately see to which subsection replies pertain, and also allows for ascending or descending sorting, depending on each person's preference.

If the devs ever look on this bug and consider this improvement, maybe they can opt to keep the current thread sorting method as a choice (via Settings) for those in love with the current legacy style, and offer everyone else a more elegant alternative that allows sorting; that's where a Git-style tree may fill a technical gap, since the current threading style is completely incapable of fully sorting either ascending or descending.

(In reply to Anje from comment #63)

I'm still not convinced that it would work.

Other like me are.

If thread is collapsed, the last new unread thread will disappear from view when a reply to it is received, so if you have not read the first email and you select the reply email now at top, - after all how would you know there was a difference - they have the same subject - you are in effect reading the answer before knowing what the question was in the first place. You would still need to expand and check for any unread previous emails, so you do not misunderstand the last email which is now displayed first. It seems to be creating a different kind of problem.

That is why the last message received appearing displayed as unread (or the first one of all unread message in the thread but that may be circumvallated) when the conversation is folded would be handy (instead of the root message appearing as read) with an overlay icon on the thread icon indicating how many new unread message are available in the thread would be handy. If there one or more unread messages you would therefore know immediately, contrary to today where you don't know (and can miss messages) until the thread is unfolded.

You would also actually see the folded thread at the date of the latest message receive (or the first of all unread message in conversation if you prefer) in the message list and see clearly right away that some new message have been received and unread yet in the conversation...

I suppose it's down to preference.

Yes it should be at user preference (and not developer preference) but currently it is not, that is part of the point of this bug report :-)

For any conversation or reading a book - I read left to right and down. So for me it is highly illogical to read in reverse. As a conversation expands I like emails appended below. That's where I expect to locate the email. If I need to re-read some comments prior to latest email, then the process of reading downwards is natural.

Yes but a book is static you cannot sort the text, move it or else you can only turn the page and read it in order it has been written. That is not the case for email that you can process and display in various ways "at will".

Currently Thunderbird allow you to do much more than a book. A simple example is I can order the list of messages by ascending or descending order... that is my user choice and preference... I cannot reverse the order in which the book was written :-)
I should be able to do the them with thread or which message appear at the root of the thread when folded in the exact (or similar) simple same way as ordering by column. Computer processing allow re-ordering data in an order that brain can process easier based on user choice and way of processing large amount of data. The all point of an application like TB is to be able to re-arrange the view of data so it is easily and intuitively accessible and not hidden by default... allowing to re-order when needed in an adequate way for the end-user to see/find quickly information it is looking for, or get notified of new info.

TB is not meant necessarily to be read like a book... personally I would also love to see the conversation in the preview pane in reverse order with the most recent message at the top... to access it quickly when reading... it is technically possible and for those that want it, it should be possible. Alec mentioned to revamp that a bit like google with conversation in ascending order but few last message showed while other older ones are folded above... but it is not to the liking of everyone. Why not to allow conversation the last message to be visible at the top and to show the conversation in reverse order? As I read from top left to bottom right it would allow me to quickly access the last up-to-date data... if it is an answer to a previous message I have not read, I can scan history by going down... instead of targetting down first and going back up...

I think it may be to do with the way the brain works... while we may read from left to right, top to bottom, to access quickly new information it is easier to access it quickly via top left that bottom right...

Maybe both the new/unread thread improvement and the reverse threading will get implemented.

That would be great...

(In reply to Anje from comment #65)

(In reply to adrmusina from comment #64)

(In reply to Anje from comment #63)

If thread is collapsed, the last new unread thread will disappear from view when a reply to it is received, so if you have not read the first email and you select the reply email now at top, - after all how would you know there was a difference - they have the same subject - you are ineffect reading the answer before knowing what the question was in the first place.
You are already suffering from that right now; the current version of TB offers no indication of how many unread replies are in a thread.
And the subject is the same currently, always, no matter how many newer replies you have in the thread. Namely, it's always the subject of the original mail.
So, it looks to me that you're complaining more about the current situation.
I'm not suffering from that situation. it's impossible because the new email is not displayed on a collapsed thread. The original root email is displayed.
I expand thread and immediately see the new emails appended in the order a person would read if reading left to right and down.

What adrmusina meant is that you are suffering from the fact that if the root email has been read, the folded thread appears as read and therefore unless you unfold it manually and consciously (or change view to unfold all threads), you cannot see you have received new emails within a thread. That is what we are all currently experiencing. This is issue is multiple: which message to display when thread is folded(currently oldest root email), which status (expected unread for last message received, but currently status of root email usually read), at which position date the folded thread appear in the message list, and finally notification about new message available in the thread itself, if more than one received.

Perhaps I've misunderstood your proposal. Perhaps it will still initially sort on the original root email and all threads therein are still hidden which is really the same in that respect.

The other one concern the thread itself when unfolded how it should be displayed, in which order messages within the thread/conversation shall be displayed. This is a separate issue. If message list show messages in descending order (newest to the top) it would be nice (or at least have the possibility to see messages in the thread in descending order as well. it would create some intuitive homogeneity to the display of messages. Then that posed the question to identify which message was in response to a parent message... having a graph help identify and answer that question visually/easily.

Does that make more sense?

That's what my proposal aims to fix. Today you don't get mails appended at the end of the thread. They get appended to the immediate parent, to which they are a reply.
Agree, they get appended because it may occur one initial email gets sub threads as people refer to separate sections of the original, so at the moment the emails get appended to the correct sub section.
The ascending or descending order, as you say, is a matter of personal preference for everybody.
With the thread-tree I'm proposing that would be as simple as sorting the thread descending or ascending. Currently, any of these two is an impossibility.
I agree, it sounds ok and would work very well providing the conversation is purley linear but if there is subthreading then it ignores it and that may not be helpful.

The proposal of adrmusina take into consideration the sub-threading sections there just displayed differently and the adjacent graph highlight them quite nicely. So you always know which message was a replay from which parent message.

I always assumed the Ascending and Descending order related specifically to the root/initial email sort and not any threads therein.
So the threads would be in conversation order and relate specifically to any subsection, so you can see immediately which sub section they are discussing. If the sub threading is removed then threading fails.

At the end again, it should remain user choice how the thread can be displayed... with more adequate default views and easy access to change the view as needed the same way we can easily change column order, activate/disable thread, fold/unfold thread... there is no intention here to force anyone into a specific thread view, just to enhance current TB capabilities beyond its current limits...

Kudos to everyone in this thread for diving deep into usability and searching for an optimal solution.
I hope I'm not gonna throw a bomb in here, but we're working on the new mail thread UI and the new conversation view, and the general idea to simplify things is to the following:

• The message thread pane will only show 1 level of indentation in order to simplify that UI and ignore the "hierarchy" in that cramped area.
• When the thread is selected, the new message will be shown as opened and visible in the conversation view.
• The conversation view will have an option to show the "real hierarchy" with a timeline like UI similar to a git flow (we're still experimenting with that, so early stage).

Making the most recent, or last received/unread, message visible immediately when clicking the thread, will drastically mitigate the need of actually opening the thread inside the message thread pane, since user can keep it collapsed and only interact with the larger and more comfortable conversation view to see the full history of replies, and quickly expand and collapse messages.

We're considering adding a "sort" up/down option in the conversation view if users prefer new messages showing at the top or at the bottom. Changing that will also change the sorting in the thread pane.

Stay tuned for a post in the UX list with mock-ups and request for feedback.
This is a though section that needs a lot of fine tuning and simplification, but still keeping the power and flexibility users need.

(In reply to Alessandro Castellani [:aleca] from comment #69)
This sounds great, can't wait to see the new "goodies".
In my humble opinion, the new UX from v102 has a really "fresh" feel, and is more eye-candy than I've seen it in years.
So, whenever these things you mention will arrive, they'll be the proverbial cherry on the cake...

(In reply to Alessandro Castellani [:aleca] from comment #69)

Great to hear there's some deep thought going into how messages are presented. (And good to see Thunderbird evolving once again - profound thanks, to everyone involved!)

My own needs are simple. All I was hoping for was a solution to the problem that launched this thread: "Group By" with days sorted "Today" at top, "Older" at bottom AND messages within each group sorted newest at top, oldest at bottom.

However, if Threaded views become more flexible, I'd certainly give them a shot as well.

Have any of you worked with Scrivener? It takes word processing to whole new level by offering multiple easily-configurable views on the material. It's a powerful approach, too often lacking in commercial software these days. Dealing with a novel-length manuscript, or dealing with a decades-long backlog of email, are problems that have much in common.

Having read this entire thread in detail, I -think- there is possibly some misunderstanding of the issue and perhaps significant overcomplication of the solution going on.

The fundamental stumbling block seems to be clarifying that those of us who prefer most-recent at the top -may- also intrinsically prefer reading from bottom to top for the purpose of -lists-. Yes, traditional paper literature doesn't work that way, but most digital documents open at the top so the habit of inserting todays event, notes, updates, bug reports or whatever at the top when making a list (and only a list) is a fairly common preference of a minority of which I am a part of. (If it helps, think of it like visualising memory Stack(s), most recent at top.)

So what I (we I think?) are asking for is actually just that the threads (aka a list within a list) simply also be mirrored vertically, with no other changes. Thus the current flow of:

Message 1
Message 2 - Thread response 1
Message 2 - Thread response 2
Message 2 - Thread response 2 - SubThread response 1
Message 3

Simply becomes as follows when the date order is changed:

Message 3
Message 2 - Thread response 2 - SubThread response 1
Message 2 - Thread response 2
Message 2 - Thread response 1
Message 1

Nothing complicated. Nothing deeply crazy. No fancy coding. No rearranging thread sequences. Just that if we are inverting the order of the date list I (possibly we...) would like to see the thread list also inverted. A simple "also invert threads when date is inverted" option. So we can read the thread list(s) fluidly from bottom to top, fully chronologically reversed. Thus most recent appears logically where our upside-down brains prefer it.

I hope that's useful food for thought to whoever may read it, and that I've not missed the mark too wildly :) Peace.

This discussion was opened 15 years ago and the option to sort threads by "most recent email at top" ( of thread) still isn't a thing.
Real life example.
I use thunderbird as my email client for my entertainment booking business - I have 100's of threads so I can manage the massive communications with clients - scrolling down to the bottom of a message thread to open the latest response is counterintuitive, time wasting and annoying.

To find out various pieces of info or coms I then having to scroll UP to open other emails to find various responses -this is also frustrating and counter intuitive.

It also means that as a business tool I can not easily see changes to the subject -as these are buried in the thread - why do I need this? Because a client might ask for specific info and I change the subject so its easier to find.

It may be days, weeks or months between correspondence and as I have no method of easily tracking where the booking process is because the message thread is always by original email and not the latest email.

Surely surely surely an option to view threads by latest email first is doable.

Alessandro, Ryan,

What the plan from the dev team to resolve this bug that has been extensively discussed in the past two years.
A bit sad that such improvement were not implemented yet as part of the Supernova revamping for 115 stable version issued this summer.
Will it be on the roadmap for the next stable version next year?

Regards,

To fix this we need to go through some substantial clean up and database rebuild.
We want to fix this and we will, but we don't have a timeline yet.
Apologies for the inconvenience.