Closed Bug 72493 Opened 19 years ago Closed 17 years ago

support threaded, sorted view


(SeaMonkey :: MailNews: Message Display, defect, P2)



(Not tracked)



(Reporter: alecf, Assigned: Bienvenu)


(Blocks 1 open bug)



(2 files, 3 obsolete files)

As much as I love the new mail, I have become really spoiled with being able to
sort and thread at the same time. Even if I could just sort by date (as opposed
to arrival time) I would be very happy :)
same here
I don't see how I'm going to add this feature back before the next release... 
Target Milestone: --- → Future
it is very UN-intuitive that it doesn't work - i've *allways* wished NC4.x had
this :)
*** Bug 73359 has been marked as a duplicate of this bug. ***
OK, this is easy enough to do in the back end, as I explained to Alec privately
(actually, a lot easier than what I told you, Alec) - basically, we just need to
not expand the threads before sorting. But there is a UI issue - clicking on the
column headers to sort does a flat sort, not a threaded sort, and I think that
is a wildly desirable behaviour - the way 6.0 worked just sucked. So, we need a
UI to sort threads. Alec suggested a hidden pref, which would work as a last
resort (the pref would just say sort_maintains_threading or something like that.
I would not be horrified if the sort menu actually maintained the threaded
state, and clicking on the column headers was just a shortcut for turning
threading off, and sorting. Or, we could make it that clicking on the thread
column header kept the current sort (so, if you were sorted by date, and then
clicked the thread column, the threads would be sorted by date). I'm open to
suggestions here - the only thing I feel strongly about is that clicking the
columns should do a flat sort. Opinions?
OS: Linux → All
Hardware: PC → All
The thread spool button could have multiple states: click once to make 
threaded, click again to depress it which locks you in threaded mode (so 
clicking another collumn will sort w/ sort_maintains_threading) clicking the 
thread spool button again would reset (and the button would stop being 
>Or, we could make it that clicking on the thread
>column header kept the current sort (so, if you were sorted by date, and then
>clicked the thread column, the threads would be sorted by date).

This would be ok.

Or as timeless mentioned, we had once discussed having the Thread column be a 
button.  Pushed in - on, pushed out - off.
*** Bug 73440 has been marked as a duplicate of this bug. ***
*** Bug 72793 has been marked as a duplicate of this bug. ***
I don't really like the three button click combination idea because it would add
an addition level of complexity that would confuse most users. 

A folder view is either threaded or not. The other collumns are sorted ascending
or descending. That's as simple and intuitive as it gets. IMHO.
*** Bug 74114 has been marked as a duplicate of this bug. ***
- As it happens to be at atm (as suggested by Peter Lairo) limits functionality.
See <>.
- bienvenu's suggestion does not limit functionality, but is completely unintuitive.
- jglick's option in the screenshot (6.0 behaviour plus visual clue) is very
intuitive, but means one more click for user who don't like sorting *and*
threading (see arguments by Adam Lock recently on .mail-news).
- timeless' suggestion is not too intuitive either, but satisfies all user
requests without a pref.

I completely disagree with Peter Lairo. Otherwise, I don't have a too strong
OK, if ya'll insist on calling bug 72793 a duplicate of this bug, please explain
to me what the relationship is between the problem shown in the screen shot at and the sort
functionality discussed here is. Maybe I'm thick, but I don't get it.
Actually, supports my suggestion
precisely. Look at items...

6. "Now you're done threading!" (threaded or not - ONE STEP)
7. "Now, sort the siblings" (date, sender, subject, etc. - ANOTHER STEP)

It is abundantly clear that threading and sorting (date, sender, etc) are two
completely separate steps in the process - locically, and therefore should be
UI-wise too.

For this reason (and because it's more intuitive) I strongly suggest that one
should be able to click on the thread header and the date/subject/sender headers
*INDEPENDANTLY* of each other. You're either threaded or unthreaded *AND* you
can sort the other collumns.

Example 1: Sorting by date/descending should *not* unthread a threaded view. 

Example 2: Threading an unthreaded view should retain the previously selected
sort order (e.g. date/descending).

NOTE: I am always talking about selecting *threaded/unthreaded* and *sorting*
(date, subject, etc.) as selected by clicking the collumn *headers* (NOT menu
access, which I don't care about).

Suggested specs:
1. When unthreaded, sorting collumns (date, subject, etc) does a flat sort (top
to bottom - straight through).
2. When threaded, sorting collumns sorts the messages within their hierarchigal
levels. So, for example, if threaded *and* sorted (by date/descending), all
level 1 messages would be sorted (by date/decscending). The Level 2 messages
would be sorted (by date/descending) WITHIN their respective level 1 parents.
3. Selecting to sort should not unthread a threaded view (these are SEPARATE items).

Threaded &                      Threaded &
Sorted (date/ascending):        Sorted (date/descending):
L1-M1                           L1-M2
    \-L2-M1                         \-L2-M2
    \-L2-M2                         \-L2-M1
L1-M2                           L1-M1

please also read "Plus my pet peeve..." on the web page given above, which
further explains why we also need to remove "Thread" from the "View - Sort By" menu.
Peter Lairo, I misread your earlier comments. Sorry.
I know some people hated the 6.0 UI, but I actually think it makes sense for
what we're trying to accomplish (and I think it's what Peter Lairo is
describing).  That said, I often found myself having to do two clicks (unthread
and sort) to accomplish something that used to take me one click (just click on
date to unthread and sort).  I'm not sure of a good solution because as Ben
points out, all of them have problems.  If we keep 4.x behavior then I don't
think this is so important to implement because I don't think it will be easy to
figure out.  I'm starting to favor the locked version of the thread column to
allow both of these usage patterns.

The other issue that Peter brings up is what to do about sorting children.  6.0
sorted the children as well, but there was some debate as to whether sorting
should just apply to the top level and children should be sorted by order
received.  In terms of reading a thread I think it makes more sense to do the
I disagree with just sorting level 1. If sorting by date (ascending or
descending), then the children should be sorted that way too. This would be very
similar (probably even the same) as sorting children by date received. BUT, if a
user wants to sort by sender or subject (*also* the children), we shouldn't take
that possibility away from him.
You're not going to get sorting within the thread without a lot of work on our
part so it's pretty much a moot point for this release. Feel free to argue about
it, but be aware it's not going to be implemented any time soon.
For good features, I can wait. ;)
I just want the threads to branch out properly, as described in bug 77965.
Currently things get very badly jumbled up in threaded mode. As long as I can
sort the parent messages however I like, I don't care how the child messages
sort (although when sorted by date and time, they should be organized so that
the bottom messages are oldest when the bottom parent messages are oldest and
vice versa).
*** Bug 77965 has been marked as a duplicate of this bug. ***
Priority: -- → P2
This appears to be a dupe of bug 78767.

I *strongly* agree with Peter Lairo that sorting by date should not disrupt the 
display by thread.
NOOO, if anything, the *other* bug is a dupe of this one - this bug is older and
contains *FAR* more useful info.

Could someone PLEASE put in some keywords so this bug will get some attention? I
suggest: mozilla0.9.2, UI, nsCatFood
Keywords: mozilla1.0, ui
*** Bug 78767 has been marked as a duplicate of this bug. ***
Since there seems to be strong forces in both directions; "automatically 
unthread when sorting" and "sorting does not affect threading", wouldn't this 
qualify a pref. I would recommend something like "Atomatically unthread when 
sorting (and remove sorting when threading)".

Also I'm too of the oppinion that all threadinglevels should be sorted, but 
it's IMHO not as important as getting the first level sorted.
There's an option in the menu for this (View>Messages>Threaded). Right now this
enters threaded mode, but at the same time it sorts messages by received order.
(Also, you can't deselect this option, because of this behavior.) It should be
changed to only thread the messages and at the same time sort the root messages
in current sort order (i.e. subject descending, date ascending). Users who
expect the threads to unthread when they sort won't be disappointed, because
that will still work, but users who want to sort by, say, date ascending, can do

Click the Date button until it's ascending.
Click View>Messages>[ ] Threaded (becomes [*] Threaded)
Messages are now grouped by thread and the root messages are sorted by date
ascending. Also, the next time you hit a sort button, it will keep sorting by
thread until you go into the menu and deselect View>Messages>Threaded.
The view - sort by - threaded item must be *removed* from the menu. Threading is
NOT sorting. Threading is "Grouping"! Therefore, the threading collumn and the
other collumns must be treated *separately*. 

It is not enough to do it correctly in the menu; it must *also* be done
correctly when clicking the collumn *headers* (threading is separate from
sorting). The threading collumn needs to be an ON/OFF toggle.

Once again, threading is *not* sorting, it is a "grouping". Groups are not
necessarily sorted (by what?), they are merely grouped.

To refresh your memory, please visit and
read steps 6 and 7 (or see my comment from 2001-03-31).
This should be a pref.

I happen to like the way way threading works at the moment because 
it's easy-peasy to flit between threaded, date, name, back to threaded and so 
on. For usenet this is an extremely important feature. Putting extra clicks or 
menu selections into this process would be extremely aggravating. 

If other people want to sort by other things and keep threading enabled, then I 
think it should be a pref. Personally I find the brain-dead flat grouping 
behaviour found in MS Outlook to be a total waste of time.
Adam: I'm glad *you* like it that way, but *I* sure don't (opinions on this are
much more divided than you choose to think). You don't need a pref for this,
there's already a menu item (which is currently useless). My suggested behavior
would make a pref unnecessary. All it takes is putting a check by/clearing a
check from this menu item to switch between always threaded to the way it is now
(bizarre, but this seems to be what you want).
So you're agreeing it should be a pref then? Persistent menu options are still 
What about my suggestion on .mail-news? See threading as sorting, but allow
multiple sorts (with decreasing importance) at once.

E.g. allow to sort by From first, then, within the mails with that From, by
date. Or thread first; within siblings, sort by From; within that, sort by date.

The UI could be as following:
If I click once on a column header, that criteria gets the highest importance.
All others are rearranged, but keeping their relative places.
Maybe an additional mode, where holding shift while clicking makes the the first
header clicked the highest criteria, the next header clicked the second highest
criteria etc..
As to th UI, a behaviour more consistent with windows UI and its derivatives 
would be: 
Click on a column - Messages are sorted by that column, sorting is turned off 
for all other columns, but messages with the same sorting key values retain 
their previous order.
Shift-click on a column - Previous sort settings are retained, but their 
priority is decremented by 1. The column clicked becomes current top-priority 
sorting column. Messages with the same sorting key values for all columns that 
sort retain their previous order.
Agreed. Right now you can't even sort like this in un-threaded mode. If I wanted
to sort by date ascending, then sort by name ascending, all the posts from "Joe
Average Poster" should be sorted by date ascending. But I would fix the sorting
by thread first, and worry about sort order features later.
bienvenu: What progress is being made on this bug?
no updates means no progress. I am working on other things.
QA Contact: fenella → laurel
*** Bug 86060 has been marked as a duplicate of this bug. ***
*** Bug 104551 has been marked as a duplicate of this bug. ***
*** Bug 107637 has been marked as a duplicate of this bug. ***
Incidentally, as a new user of Mozilla about a year ago, I thought for a while
that the thread column header did act as a toggle. I was viewing in date order
and clicked on the thread header, with the expected result; however, to get back
to the plain date-sorted view, I clicked on the thread header again.

Maybe this was inherited expectation from Outlook Express (happily I can't
remember whether this is true since I have been using Mail-News exclusively for
about a year), but I'd very much appreciate the thread-view being a toggle.
After all, it is (as said earlier in this bug) a grouping feature, not really a
sort option.
Comment from Peter Lairo in bug 127881:

When bug 72493 is fixed:
1. Remove: View / Sort by  / *Thread*
2. Add: View / Messages / *Threaded*
Concerning which date to use on the sort:

I am seeing a lot of cases lately where the "answer" to some message occurs in
the list *before* the question.  That is darned annoying at best.  

In some cases, the message date is utterly bogus - because the sender's clock is
wild.  The easiest way to handle that is to live with it; a more-difficult but
"neat" way would be to pick up also the earliest date on a "Received" header. 
The received headers are applied as the message passes through the net among
MTA's that are likely more careful about time than the home user.  If the
sender's date is (a) after the earliest "Received" date, or (b) more than 48
hours before the "Received" then simply disqualify the sender's date and use the
earliest Received.  This whole later part is very much a "nice to have if we
weren't so damn busy" change.  What is important, to me, is to be able to read a
thread as a conversation - the question followed by the answer.
mailsmith ( uses the latest received header date for the message
date. When no recieved header dates are available, it uses the message download

At first glance, this seems a bit backward. Why use the "latest" header? This
could end up in conversations being read out of order just because John's
message got routed through fifteen servers before it made it to you, so you see
Mary's reply to John's message before you see John's message. This is a valid

However, the alternative is to use the earliest received header date. The
problem with this (as with using the Date: header itself) is that early received
headers can be forged while later ones are not forged. Mail clients that trust
Date: headers or early received headers for date information allow spammers to
sort their messages to the top of your inbox queue by sending out messages with
next year in the date.

So, I'd rather see the occasional out-of-order conversation (due to slow
servers, not client date misconfiguration) than give spammers the ability to
jump to the top of the queue.

my 2bits
RE: "Mail clients that trust 'Date:' headers or early received headers for date
information allow spammers to sort their messages to the top of your inbox queue
by sending out messages with next year in the date.

Sad but true, regarding Sender's date; I've never seen a 'Received:' date
forged.  However, it could be ameliorated somewhat by totally disqualifying any
date more than 7 days [arbitrary] before 'today.'  The network is never so slow
that a message gets queued that long.  Likewise, any future date must be

Personally, anything in my inbox with an obviously bogus date goes immediately
to trash without passing GO.
> Sad but true, regarding Sender's date; I've never seen a 'Received:' date
> forged.  However, it could be ameliorated somewhat by totally disqualifying any
> date more than 7 days [arbitrary] before 'today.'  The network is never so slow
> that a message gets queued that long.  Likewise, any future date must be
> disqualified.

It is possible. If we used the first (chronologically) Received: header, it could potentially be created artificially by the author of the message. However, if we use the latest Received: header, it will come from the reader's own NNTP and be reliable.
but if spammers don't do it, then why bother?

I would think that since they don't do it there is probably a reason. Possibly 
becuase there are more forged-dates filters then there are people with so much 
unread mail that there would be a noticable advantage to have an old date.

And what says that they would only forge to an old date? I know that in my 
inbox it would only be an dissadvange with an old date since the mail would end 
up amost my old read mail and not among my "read today" mails.
> but if spammers don't do it, why bother.

Spammers *do* do it. I've received spam this month (yes, in the last eight days)
with both pre-dated and post-dated forged date and received headers. One would
sort to the "wrong" end of some users inboxes, and the other would sort to the
"right" end.

If you can think of it, spammers already do it :(

ok, so if spammers forge in both directions we are in a no-win situation. So 
IMHO we should just ignore spammers and use the first date, that way we get it 
right with most of the mail in the mailboxes.
I'm with Jonas on this last comment.

Also, re: "However, if we use the latest Received: header, it will come from the
reader's own NNTP and be reliable." --

It would be reliable, but also would contain all the network delays and it would
be the same as "order received."  The purpose [for me] of trying for a reliable
"time of origin" is to get the question sorted before the answer.

Hacked dates tend to stand out because they are way out-of-band.  The problem
cases arise because not everyone synchs her pc clock and so innocently issues
mail with bad timestamps.
Hmmm.... after reading through the comments on this bug, I think I'm a bit
unclear on the objections to the recent suggestions re: date sorting. I think
some folks are thinking that I'm talking about a date sort *instead* of a
threaded sort. I'm not. I'm talking about a date sort within the threaded sort,
or by itself when threading is turned off.

My notion of a threaded view is that it follows "References: " headers
primarily, and *possibly* subject lines where References headers are not found.
No other factors are relevant. Dates *could* be used to sort two replies
relative to a common original message, but this isn't cruicial in threaded view
because the important thing is that they're both replies to the original
message, not that one reply was sent and/or recieved sooner than the other.

As I understand this bug, it's about adding that non-crucial secondary sort by
date within a threaded view. Setting that aside for a paragraph, let's look at
how a threaded view works without any secondary sort...

If you follow References headers, then threaded view will work for all well
formed messages, and will always nest answer messages within the question
message to which those answers are replies. So, date sorting really doesn't
impact things at all. If the threaded view is built off of Refernces headers,
and you read your thread by first reading the "outer level" message before
reading the "nested inner messages", then you'll always read the question before
the answer (assuming the answer was sent in reply to the question and the
References header was properly added to the message). Things will work even if
users maliciously coordinate bad date values and forged Received headers to
screw with sorting by date.

So, I don't see how the objection of question/answer order is at all relevant.
When threading, well formed messages always make it painfully clear what is a
reply to what. Outer messages are "questions" and inner messages are "answers".

Now we introduce the secondary sorting (by date in this case, but it could be by
anything else like sender, message length, or by number of capital letters in
the From header).... This means that if Alice sends a message and Bob replies to
Alice's message and Claude also replies to Alice's message, then because it's a
threaded view the messages from Bob and Claude will both show up nested under
Alice's original message. The secondary sort just determines whether Bob's
message appears before or after Claude's. If Alice wrote a question, and Bob and
Claude each wrote answers, then you'll be reading Alice's question before either
answer no matter how you sort the messages from Bob and Claude. This secondary
sort just determines *which* of the two answers you read first.

    Alice question
        |--- Bob answer
        |--- Claude answer
    Alice question
        |--- Claude answer
        |--- Bob answer

So, no matter *what* method you use for your secondary sort within the threaded
view, the underlying fact of the threaded view ensures that you read questions
before answers.

Now that that's settled, my recent comments were directed at a reasonable method
for sorting messages by date.

PC users accidentally and intentionally set their dates wrong all the time. Some
folks just don't know whether they're in daylight savings time or not. Others
never set their time zone when they buy their machine. Still others
intentionally set their dates to avoid licence and shareware expirations. Some
folks have battery problems that throw them back to start-of-epoch everytime
they power down. Mail/News servers tend to be more reliable. This argues for
using Received headers (or download time) for date sorting.

Spammers intentionally forge date headers and also often forge the first couple
of recieved headers stuck on a message. (One way of catching some spam is to
follow received header chains and spot those forged headers.) So, the first
couple of received headers (the ones "lower down" if you're viewing all headers
in a mail message) are not reliable. More recent received headers are more
reliable. Hence, my suggestion that date sorting should follow Mailsmith's lead
and sort by recent received header or download date when that isn't available.

If question/answer relationships are important to you, sorting by date using
this method within a threaded view will not destroy these relationships or hide
them in any way.

If you sort by date with this method outside of a threaded view, then yes, this
method may sort some answers before their questions. However, I suspect that it
will do so far less frequently than end users's own clock settings would do if
you were to use their date headers to sort by date. In any case, if the q/a
relationships are what interest you, you should be using threaded view rather
than date sort as your primary message organization.

As I understand this bug, it's about a second level of organization, within the
threaded view, and so the objections to this method of date sorting are not

Hope I managed to clear up any confusion about my suggestion :)

Matt - Yes, 100%, clear as a bell.

I am comparing to current (2002-03-06) behavior.  In "Threaded" view that
/appears/ to be order-received within thread, although the Great Lizzard alone
knows what the order of level-one threads might be.  In this case answers show
up before questions with confusing frequency.

Does that mean that the current behavior does not use the "References" or
"In-Reply-To" info to structure threads?
I don't see how the discussion about the specifics of how the siblings in thread
groups are sorted (what headers to pick dates from, how spammers may mangle
headers that contain time information) is at all relevant to this issue. The
issue is that siblings in threaded view cannot be sorted; the only available
sortings apparently are sorting the thread root messages by date

I am under the impression that the descendant message groups in threads are
currently unsorted and appear in order received, but I could be wrong...
However, that is of relatively small import; the important thread sibling group
is the root group, i.e. the sorting of the thread root messages. Currently, it
is not possible to enjoy the benefits of threaded view, while sorting the
threads to bring together:
 - threads started by the same author
 - threads started with a message with the same subject
 - threads where the root messages are
   - flagged
   - labeled with the same label

...and there are others of course, but these seem to be the important, useful
ones. Please consider putting some effort to implementing this after 1.0?
Oh, a related rfe which looks to my untrained eye a bit expensive and kind of
messes with the whole simple sibling sort idea, but certainly would seem useful
-> bug 122780.
IMO, Tuukka has it right about the non-relevance of "what a spammer might do."

To me, Bug#122780 could be subsumed as a dupe of this one.  I didn't see that it
added much or contradicted anything here.  
Jaime's algorithm, to the extent I was able to follow it, seems spot on!!  It
rather frosts me that NS already has implementing code but is sitting on it.

As I look over the Internet Draft that proposes a threading algorithm for IMAP,
it occurs to me that a neat unification of methods would be to have the POP
back-end present itself to the front-end as an IMAP server!  The SEARCH and
THREAD, etc. functionality looks like just what the Dr. ordered; might as well
simply grab all the functionality in one swell foop.
Actually, bug 122780 is slightly radical in the sense that there the sorting of
sibling messages would be by the maximum of an attribute over all the messages
in the thread under each message in the sorting group; as the stuff here is just
vanilla sorting sibling messages by their own attributes, I'd rather not have
complicate this bug with that... Bug 122780 seems to me a bit hairy ui-wise too,
so I just mentioned it here as someting to maybe consider taking into account in
figuring that sort of stuff in the context of this bug.

.02?: 2-state threading toggle.
*** Bug 132809 has been marked as a duplicate of this bug. ***
*** Bug 158539 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
adding my vote for this feature.  it's the key reason i still use Outlook
Express for most of my newsgroup reading.  also, though, i want to be able to
sort by flagged/labeled threads.  it is frustrating that i can only flag a
single message, not a whole thread - i'm off to find another bug that might
cover that.
Blocks: 164421
*** Bug 173054 has been marked as a duplicate of this bug. ***
*** Bug 142705 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
Blocks: 176238
I'd recommend that you go with the idea that threading be totally independant of
sorting, and then make this be a blocker for bug 116075 - threading after
quicksearch - this way you can thread independantly of sorting or (quick)
searching.  I think that the idea of sorting with sub ordering should be a
separate bug so that it need mostly affect only the sort algorithms.  That is,
if threading and sorting can be, or are, separate of course.  
this is unrelated to the quick search threading bug, at least in terms of
implementation. We can implement sorting of threads fairly easily. Threading
quick sort results is a bit harder, and completely separate.
*** Bug 184845 has been marked as a duplicate of this bug. ***
Re: comment 5

"clicking on the column headers to sort does a flat sort, not a threaded sort, and I think 
that is a wildly desirable behaviour"

I disagree.  When in a threaded view, I prefer clicking a column header to sort _the 
threads_, rather than the individual messages.

Re: comment 6

I just as well think that a three-state thread spool is pointless.

The way I would do it is to simply have the thread spool as a toggle button.  Clicking a 
column header would then sort the threads (if threaded) or the messages (if unthreaded) 
by that column without altering whether the view is threaded, rather like in Outlook 

Re: comment 15

Your diagram is inconsistent - I presume you meant

Threaded &                      Threaded &
Sorted (date/ascending):        Sorted (date/descending):
L1-M1                           L1-M2
    \-L2-M1                     L1-M1
    \-L2-M2                         \-L2-M2
L1-M2                               \-L2-M1

But if sorting within threads is going to be implemented, it ought to be an option.  There 
are some of us who like a logical, usable sorting of threads (subject or whatever) while 
also finding that it makes sense to see replies to the same message in the order that they 
were posted.
Blocks: 20385
I would like to reiterate that this bug does not address the issue of "dupe" bug
122780 -- sorting thread by youngest message.  I find this crucial to threading.
 It is why I cannot use Outlook Express threading -- new messages in old threads
go unnoticed, as they are sorted to the bottom of my mailbox.

Please retain this feature request, or add this request as part of this bug. 
Currently, the only way I can use Mozilla mail threading is to remember to
frequently switch to "View->Messages->Threads with Unread" and back to make sure
I haven't missed mail.  I've read the infamous JWZ diatribe on thread grouping
and sorting, and realize that my request conflicts with what he says.  However,
it remains a key usability issue of threading, at least in mail.  In news, one
is less likely to be tracking and responding in a timely fashion to a specific
thread, so it may be less of an issue.

Keywords: helpwanted
Blocks: 205669
Bug 205669 was duped to bug 135326.  Replacing in blocks.
Blocks: 135326
No longer blocks: 205669
Blocks: majorbugs
For now, what I'm going to do is add back the View | Messages Threaded toggle
menu choice, add a pref to make clicking on a field column optionally do a flat
sort, and implement sorting top level threads by subject, sender, etc. The
toggle menu is needed for users who have the pref for clicking on a column doing
a flat sort turned off, and who want to do a flat sort.

Sorting siblings within a thread I'm going to leave alone for now. However, this
could be implemented in ::ExpandByIndex when we expand a thread, though we'd
need to re-factor the sort code so that it can work on arrays other than the
main view array.
As I understand your implementation, I will be able to keep my view threaded,
and also be able to sort by another column (rather than just limiting it to sort
by Date).

That's a nice improvement, but still does not solve the greatest useability
problem of this View -- the tendency new messages on an old thread to disappear,
due to the sorting of the thread Date by the Date of the initial email of the
thread.  For example, the email notification of the latest bug update for this
bug was added to the thread that started in my Inbox on 3/29/2003, and is
therefore buried many pages down in my Inbox.  The only way I can find it is to
notice that I have new email in my Inbox that I cannot see, and select View
Threads With Unread.

> The toggle menu is needed for users who have the pref for clicking on a column
> doing a flat sort turned off, and who want to do a flat sort.

Can't you just use the threading column header (the little button with the
balloon) to swtich between threaded and flat, like it used to be 2.5 years ago?
Currently the thread icon toggles the sort order of threads, so click it once,
oldest threads at the top, click it again, newest threads at the top. This is
somewhat consistent with the other columns but more importantly, making it
toggle between threaded and not would lose the ability to reverse thread sort.
Unless, as I said before, it had three states - out (not threaded), in + down,
in + up. 

Kirby, I understand what you want but that doesn't mean I have time to do it :-(
Attached patch proposed fix (obsolete) — Splinter Review
This adds back the View | Messages | Threaded toggle, and makes it so that by
default, clicking on a column sorts the threads instead of unthreading and then
sorting. In the backend, I added a SortThreads method, and cleaned up a lot of
the formatting.
Attached patch proposed fix v2 (obsolete) — Splinter Review
This patch incorporates some review comments, adds support for remembering the
state of expand/collapse all (bug 64426), and fixes some bugs in the previous
patch. I think this patch is OK to checkin, but I'll test some more.
Attached patch v3 fix bugs uncovered by testing (obsolete) — Splinter Review
fix threaded indicator when sorted by other than id, reverse sort threads by
subject, sender, etc, fix tree assertions
Attachment #127275 - Attachment is obsolete: true
Attachment #127632 - Attachment is obsolete: true
Attached patch cumulative patchSplinter Review
this makes it so clicking on a column unthreads, by default, controlled by a
pref, +pref("mailnews.thread_pane_column_unthreads", true);
Attachment #127665 - Attachment is obsolete: true
OK, this is checked in, r/sr=mscott. In order to sort threads by other than ID,
you can either use the view | Sort by menu items, or, to make clicking on the
thread pane columns not do a flat sort, add the following pref to prefs.js:

pref("mailnews.thread_pane_column_unthreads", false);

I still need to add a UI for this pref, and fix firebird. I'll spin off a new
bug for the former.
duh, I mean fix thunderbird
Closed: 17 years ago
Resolution: --- → FIXED
Is there a bug for Kirby's request. That's the thing I'm after too. Without it,
threaded mail seems utterly useless (and harmful) [of course, useless for me -
other people may find it useful, but I can't see how]
No, but you or Kirby could file one and assign it to me (not that I'm making any
promises :-)) . Please be specific about what you want. None of this seems
particularly useful to me so I can't go by what seems most useful to me.

For example, you could want to sort threads with "new" messages to the top (or
bottom) - that might be fairly easy to implement efficiently but new messages
are only new the first time you open the folder - new state is cleared when you
close the folder. Or, you could sort threads by order of the most recent message
in the thread (not easy to implement efficiently). Or, you could sort threads by
the number of unread messages in the thread (also fairly easy to implement

If you're really just interested in threads with unread messages, we already
have that view - View | Threads | With unread
What Kirby seems to want is to be able to have the threads with the newest
messages in them (regardless of the date at the top of the thread) at the top of
the view.  This appears to be part of bug 20385, which depends on this one.

The question of sorting messages _within_ a thread is another matter altogether.
I have clarified specifically what I would like to see in bug 20385.  bienvenu,
I did not assign that one to you (I don't feel comfortable telling others what
work to do), but would love it if you could take it on.  For all the work that
has been put into Threaded view, it would be nice to be able to use it.  

As you note, if what people really wanted to do is see only Unread messages,
they could use the View Threads with Unread.  However, I for one would like to
be able to use threaded view on a regular basis, rather than constantly changing
between different views each time a message arrives (to make sure I don't miss
timely mail).

I've just opened bug 217031 which seems to be a side effect of the fix to this 
bug.  I discovered that problem while playing around with a recent build trying 
to get the hang of what changed here.  Generally, it seems like a good fix that 
does the things I'd expect, particularly as described by Peter Lairo's comment 
15 and Tuukka Tolvanen's comment 52.  (The whole orthogonal issue of which 
criterion to use for date sorting made 50% of this bug report a red herring.)

However, two things occur to me:

First, for some reason, the   View | Messages | Threaded   menu item strikes me 
as ugly; I can't pinpoint it, but I don't like it.

Second, the menu item   View | Sort by | Thread   still exists, tucked into the 
middle of the list as if it were a sort order.  If the menu design were up to 
me, I would eliminate 'Threaded' from   View | Messages   and then move 'Thread' 
in the SortBy submenu into a separate menu group (as 'Threaded' is currently), 
but at the BOTTOM of the submenu.

I suspect Peter Lairo would argue against my menu design, that 'threading is a 
grouping, not a sorting' -- but really,   View | Messages  is FILTERING; not 
sorting, not grouping.  To my mind, grouping and sorting are more closely 
related to one another than either is to filtering.

I can't see a reason why those two menu items would behave differently -- but in 
fact, they do:
  Messages|Threaded   threads things incorrectly (per my new bug); and 
                      leaves the sort order alone.
  SortBy|Thread       threads things correctly; and 
                      sets the sorting to Order Received.
I think one menu item which sorts correctly and doesn't change the sort order is 
called for.

Finally: with the hidden preference in its default setting, clicking on a column 
header now behaves differently from selecting a sort from the menu  --
the menu *always* sorts without unthreading, but the column headers (by default) 
revert to a flat sort.  I find that inconsistency undesirable.
I have opened  Bug 219620 to follow up on my comment 81.
I have also filed a bug 219787:
"clicking thread icon in column header should switch thread view and flat view."
Product: Browser → Seamonkey
No longer blocks: 164421
Blocks: 158464
No longer blocks: majorbugs
In Bug #306125 (Optional GMail and iTunes layout (with example)) is there a mock up of how sort in threaded view in a different way.

Direct link to picture:
Keywords: helpwanted
You need to log in before you can comment on or make changes to this bug.