Sort by "order received" seems to have been removed from pull-down menu in the main mail/news window. See snapshot attached. "Order received" used to be the last selectable choice after "Total". I was using this feature all the time and deeply regrets it is now only available through View > Sort By > Order Received.

When the tree was converted to an outline control the Order Received column was't transferred - I don't think this was intentional. threadPane.xul also has some typos in it.

neil, thanks for the patch and for fixing those typos. to get "order received" to work properly, there is a little more work involved. I'll attach the patch to get sorting by order received to work. (in my patch, I'm showing the message key id in the order received column) all that is left is to hide the column by default. accepting.

two comments about that patch: 1) I need to figure out how to hide the "order received" column by default 2) I'm showing the id (a nsMsgKey) as the value in the column.

I've checked in the witdth -> width fix as part of another bug. that would have fix the problem where we weren't persisting certain column widths.

This actually was intentional. The column doesn't do anything and only existed because there was no previous way to add it to the menu without adding it to the tree. I'd suggest not adding this back in.

ok, thanks for the info putterman. I won't show the column. but, part of my fix is needed to make sure insertion sorting still works when sorted by id. a new patch on the way...

If you don't have the column or any other one-click UI element, it is impossible to reverse the sort order... I was using that feature really often and I would consider having to use a menu item hidden somewhere deep in "View" as a real UI regression.

4.x had "ascending" and "descending" at the bottom of the "View | Sort by | ..." that would allow you to reverse the sort, right? jglick, should we add that back? having it in the ui (and giving it access keys) might be necessary for accessability and users who don't have a mouse.

We should have "ascending" and "descending" at the bottom of the "View | Sort by ..." menu.

marking won't fix. #72819 covers the "ascending" and "descending" menu items.

I strongly disagree with this choice and proposes to re-insert a new optional column in the outliner containing the message number/index in the folder. Then it could be possible to sort in ascending/descending order just clicking on the column's header.

reopening, until the discussion is complete.

First off, I'd like to say that this feature is _very_ important because of all the timing differences between people's computers. Without this, entire mailing lists are extremely hard for me to follow... I definitely agree with Daniel, put the extra column back in. Putting an ascending/descending option in View - Sort By is independent of this bug, since it has to do with the other sorting methods as well. I think the extra column AND the extra menus should be added, since I was under the impression that there's two different "ways" to turn on features like this in mozilla (mouse/keyboard). PS I know this is off-topic big time, but I just wanted to say thanks for an amazing piece of software (mail&news specifically). Without you guys I might have had to use that other piece of **** out of Redmond.

I second daniel's suggestion for having a column with the message no. in it. Mulberry does the same and I find it very useful. Also, the drop down menu iten should definitely be added back. I;m voting for this bug. :)

I completely agree that this should be added back to the pull-down menu. Most people will never even see that this feature is available without it being there, and yet it is an EXTREMELY useful feature!

So whats happening with this bug? Is it going to be fixed sometime soon?

is there any particular reason that the "Date" field is used as a default column at all? I can't think of why users would want to orginize their email by the sender's date at all, unless all email was from one timezone/orginization, which seems like a rare case. it seems to me that "Received" should replace "Date" entirely, even if via a pref. btw, I think Outlook and other email agents use "Received" as the default date column.

I also believe this is important to fix, and in fact "Order Received" should be the default. This is because "Date" depends on the date sent, which is computed by the sender's mail client based on the date set in the sender's machine. Often senders' machines have dates that are wildly wrong--even by years---and this has led in the past to mail that's mis-categorized or overlooked. For me, View/Sort-By/Order-Received is easily the most common function I use in mail/news, along with GetNewMail and some other sort-by (like subject or sender).

ping.... Whats happening with this bug? can we decided either way. That is either mark this as WONTFIX or INVALID OR get the patch accepted. Personally I think that the order received column is very helpful but thats just me. Also having a Msg Number which fills up the order received column is a good idea. Heck, you can even call it the "Msg#" column instead of Order Received if that makes more sense. My personal opinion, fix this for 1.0. unless ofcourse the majority of people say that this shouldn't be fixed. But from what I read, its not the case. Here's the deal. If I update the patch thats lying on this bug and submit, would you guys accept it for 1.0? Also platform/OS should be All/All.

I agree this is important. I cruise my IMAP mailbox in "order received, descending" mode. At least several times a day, I click on thread, sender or subject columns to group my mail into context. Then, to get back, I am currently forced to use View > Sort By > Order Received and then View > Sort By > Descending. A column would be bliss: click!

Another ping. This bug (and the patch) are well over a year old now! Please?

I agree. Sort by date received is be more useful, as spammers often forge the sending date, and people's PC's often have the wrong time. I miss email ALL THE TIME because it sorts to some weird place.

BTW this the OS for this bug should be set to "all" since it occurs on all platforms.

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

this patch removes "Order Received" menu item alltogether and adds a pref for which date you want to sort by when you click on the 'Date' header or do 'View'/'Sort By'/'Date'. add the mail.ignore_senders_date_for_sort pref to sort by 'Order Received'.

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

I've been running with this patch for a few days now without a problem. anyone else want to test this?

I'm happy to test it (its a great idea and the solution I was toying with a few days ago before I noticed this bug), have a Win2K build (with one patch I have just created including changes to a file you change: nsMsgDBView.cpp) but am new to this cvs/diff/patch business -- how do I apply the patch (give my working copy of nsMsgDBView.cpp is different?)

I'm happy to test it (its a great idea and the solution I was toying with a few days ago before I noticed this bug), have a Win2K build (with one patch I have just created including changes to a file you change: nsMsgDBView.cpp) but am new to this cvs/diff/patch business -- how do I apply the patch (give my working copy of nsMsgDBView.cpp is different?)

on unix: # patch -p0 < patch_file I'm not sure about windows...

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

Just to add my $0.02 to this.. It's non-intuitive to, say, click on the 'Sender' column to sort by that column when you're trying to locate an email from a particular individual, and then have to go back to the menus to select the sort option for order received. Every other field is available as a column heading - why is 'Order received' not? (Incidentally, I'd note that this is a feature I've seen in pretty much every other mail client I've ever used, and one that users tend to expect without even thinking about it. If a user is going to move over, it's features like this which shouldn't be missing). Even if the column is only hidden by default, at the very least allow it to be selected as a column by the user.

hi, i agree with comment #16: i don't understand why anyone would want to sort based on the random clock that the sender's computer had. i suggest replacing the Date field with "Date Received", adding a different column with date received, or a pref to make the Date column be date received. any of these would work for me.

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

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

Transferring owner from dup :-)

Comment on attachment 114666 [details] [diff] [review] Proposed patch r/sr=sspitzer on neils patch.

this is probably planned for 1.4. before you land, a few questions / comments: 1) what about the search messages window? 2) also, where will this column appear for existing users? (hopefully, on the far right in the thread pane) also note, distributors should be able to hide this column by making a theme change.

Comment on attachment 114666 [details] [diff] [review] Proposed patch > 1) what about the search messages window? I'm running with this change. The column makes sense for single folder searches, but not much sense for cross-folder searches. if the user expects to search across folders and sort by order received, it won't work. > 2) also, where will this column appear for existing users? (hopefully, on the > far right in the thread pane) I'm thinking users should be able to add it, but it should be hidden by default for new (and existing) users in both the thread pane and the search dialog. (similar to some new folder pane columns, like "Size", that are relatively new to the product.) 3) the menu item and column picker is "Order Received" but the column header is "ID". is this what we want? I'm going to take back my r/sr until we resolve these issues.

1. Good catch - fixed. 2. It is hidden="true" by default. If distributors have an overlay, they can add <treecol id="idCol" ignoreincolumnpicker="true"/> to stop people unhiding it, and optionally #idCol { visibility: collapse; } in case someone is sharing a profile with an enabled column 3. sspitzer 1.16 <!ENTITY idColumn.label "ID"> Need I say more ;-)

Comment on attachment 114796 [details] [diff] [review] Addressed review comments r/sr=sspitzer I think I named it "ID" because it was used only by development (patrick beard) can you change it to "Order Received" before checking in? that's better than "ID".

Fix checked in.

Maybe this should be a new bug/feature request, but I guess I mis-read this and was under the impression that the idea of adding the received column was to add received date, rather than an arbitrary index that is basically meaningless to the end user. It achieves the same thing on a functional level, but I think displaying received date makes more sense. I couldn't find an existing bug on this. Comments?

James - well it's not the same as this bug, but you already filed it and it was duped. as this bug doesn't show the received date, and there are other similar comments here, I've reopened your bug 166254 as an enhancement request for a date field. the fix for this bug is certainly an improvement, and it seems to work fine in yesterday's nightly.

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