Closed Bug 72493 Opened 24 years ago Closed 22 years ago

support threaded, sorted view

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: alecf, Assigned: Bienvenu)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 3 obsolete files)

Old screenshot from Threading on/off
5.52 KB, image/gif
Details
cumulative patch
50.05 KB, patch
Details | Diff | Splinter Review
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...
Status: NEW → ASSIGNED
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 depressed)
>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 <http://www.jwz.org/doc/threading.html>. - 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 opinion.
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 http://www.vortxweb.net/ccs-pg/bugzilla/newsThread4.gif and the sort functionality discussed here is. Maybe I'm thick, but I don't get it.
Actually, http://www.jwz.org/doc/threading.html 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 latter.
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 this: 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 http://www.jwz.org/doc/threading.html 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 prefs.
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..
ben.buksch: 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 (barebones.com) uses the latest received header date for the message date. When no recieved header dates are available, it uses the message download date. 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 criticism. 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 -matt
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 disqualified. 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 :( -matt
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 OR 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 relevant. Hope I managed to clear up any confusion about my suggestion :) -matt
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 ascending/descending. 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 Express. 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. --kirby
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. --kirby
> 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 patch — — Splinter 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
Status: ASSIGNED → RESOLVED
Closed: 22 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 efficiently). 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). Thanks, --kirby
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: https://bugzilla.mozilla.org/attachment.cgi?id=207965
Status: RESOLVED → VERIFIED
Keywords: helpwanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: