533409 - support descending order for thread tree view (not only root but whole children messages) in the message list pane

Status: NEW

(Thunderbird :: Folder and Message Lists, enhancement)

Description

[dynamis (Tomoya ASAI)]

In the message list pane, currently messages thread can be shown only by ascending time order (click spiral icon).

Some users prefer to show new message on the top of the list, not bottom of the list (time descending order). Some of them want to show descending order for thread tree view too.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Similar request to bug 479969?
Are you talking about order of root mail of main-threads? Or order of root mail of sub-threads in a main-thread/sub-thread? Or order of child mails in a a main-thread/sub-thread? Or any of them?

Comment 2

[dynamis (Tomoya ASAI)]

Sorry my comment wasn't contain enough explanations.

Similar but different request to bug 479969.
As far as I read the bug 479969 comment 12, irneb is requesting re-ordering sub-threads depending on the latest mail under the thread:
# Or order of root mail of sub-threads in a main-thread/sub-thread
https://bugzilla.mozilla.org/show_bug.cgi?id=479969#c12

I'm not requesting re-ordering sub-threads depending on the children's date.
If the order are changed when we get new mail in old sub-thread, user may confuse about it (especially if user are viewing the tree at that time) and I think we need not support it.


Anyway, My request is simple & whole reverse tree view you mentioned in bug 479969 comment 10:
> (A) Descending order by Date
>       ... snip ...
>       mail-2-1-1 (response #1 to mail-2-1 at T-2-1-1)
>     mail-2-1 (response #1 to mail-2 at T-2-1)
>   mail-2 (main mail of thread-2 at T-2)
>       mail-1-2-3 (response #3 to mail-1-2 at T-1-2-3)
>       mail-1-2-2 (response #2 to mail-1-2 at T-1-2-2)
>       mail-1-2-1 (response #1 to mail-1-2 at T-1-2-1)
>     mail-1-2 (response #2 to mail-1 at T-1-2)
>       mail-1-1-3 (response #3 to mail-1-1 at T-1-1-3)
>       mail-1-1-2 (response #2 to mail-1-1 at T-1-1-2)
>       mail-1-1-1 (response #1 to mail-1-1 at T-1-1-1)
>     mail-1-1 (response #1 to mail-1 at T-1-1)
>   mail-1 (main mail of thread-1 at T-1)

> (B) Ascending order by Date
>   mail-1 (main mail of thread-1 at T-1) 
>     mail-1-1 (response #1 to mail-1 at T-1-1 )
>       mail-1-1-1 (response #1 to mail-1-1 at T-1-1-1)
>       mail-1-1-2 (response #2 to mail-1-1 at T-1-1-2)
>       mail-1-1-3 (response #3 to mail-1-1 at T-1-1-3)
>     mail-1-2 (response #2 to mail-1 at T-1-2)
>       mail-1-2-1 (response #1 to mail-1-2 at T-1-2-1)
>       mail-1-2-2 (response #2 to mail-1-2 at T-1-2-2)
>       mail-1-2-3 (response #3 to mail-1-2 at T-1-2-3)
>   mail-2 (main mail of thread-2 at T-2)
>     mail-2-1 (response #1 to mail-2 at T-2-1)
>       mail-2-1-1 (response #1 to mail-2-1 at T-2-1-1)
>       ... snip ...

note: In descending order, we should use triangle icon (▲), not current inverted triangle one (▼).

Users tend to keep scroll position at top/button to always show latest mails.
Goal of this bug is to make user possible to show latest mail at top when they use thread tree view with descending order by date.
This view is useful for users who prefer descending order.

As for user interface, I think spiral icon to on/off thread view should be 3 mode selector (on[descending]/on[ascending]/off) not adding new button.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> Similar but different request to bug 479969.

Set dependency to bug 479969, for ease of search and tracking.

Comment 4

[irneb]

That's probably a much simpler solution. It basically turns around the entire list (threads included). I.e. expanding a collapsed thread with descending order would expand the thread upwards instead of downwards as per ascending order. However the latest email received would not necessarily be at the very top of the entire thread - similar to it not being at the very bottom of an ascending thread. It depends on which sub-thread was replied to.

Maybe this could be a temporary solution until bug 479969 can be sorted out. At least the sorting is closer to what the user wanted. I still think my example in bug 479969 is the closest we can get to a "perfect" solution. A combination of the 2 would be quite useful.