Build: 2001-11-27 Overview: I noticed different sorting of Folders in the Folder pane and pop-up menu, which appears when we 'Copy Message' from main menu or 'Copy To' by using context menu. Steps to reproduce: In my Folder pane I have folders with names started with '3': 3-pane Bugs, and folders with name started with underscore. Examples: _Access Bugs, _Context Bugs - to have them in the beginning of the tree. '3-pane Bugs' folder is located upper in the Folder pane. Click Message|Copy Message and select Account with above folders. Actual Results: In the pop-up list of folders: '3-pane Bugs' folder is located after all folders started with underscore in the pop-up list of Folders when we use 'Copy' functionality. Expected Results: Consistency Additional Information: Described is for Win2K. On Mac OSX: in the Folder pane: '123', then '_Test', but in the pop-up list: '_Test' is shown after 'Sent'. On Linux 7.1 the same sorting in both places: '123', then '_Test'.
*** Bug 115268 has been marked as a duplicate of this bug. ***
Updating multiple bugs. This is a valid UI issue. Would be nice to have it fixed if time allows.
I do not believe #112301 is a duplicate. #112301 is newly resurfaced in the 12-14-03 build!
Problem verified in release 0.9.7 ([Mozilla] Mozilla 0.9.7 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221). Folders sorted alphabetically in folder list pane. Folders listed in apparently random (unsorted???) order in the lists presented in Message -> Move Message and Message -> Copy Message actions. Previous versions (0.9.6, 0.9.5, etc.) displayed message folders in same order for Move/Copy actions as in folders pane. Problem was exercised in both Classic and Modern themes, and with startup in MailNews and Browser functions with identical results.
I just downloaded and installed 0.9.7 for MacOS X. (build ID 2001122106; Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7) Gecko/20011221) However, the list in the folder pane isn't sorted properly alphabetically. It used to be proper ASCII order, which is alphabetic among upper-case, followed by alphabetic among lower-case. This was fine. It appears to have switched to a case-insensitive alphabetic sort; but it's not quite right. For one of my accounts, the top-level folder "work" is at the top of the list, and "consulting" is at the bottom. All other top-level items are sorted correctly, tho independant of case (which I *don't* like). It should be noted that "work" is the last folder I should have, and "consulting" the first (in a case-insensitive sort). This info help? Is there a seperate bug filed to request the case-isolated sort again? Since all of the "normal" folders are upper case, and all of the ones I've created start lower-case, it made it much easier to know that INBOX was always at the top, and so forth...
Chris P. Ross comments: Is there a seperate bug filed to request the case-isolated sort again? I suppose it's a matter of taste, but I much prefer the case-blind sort.
It's somewhat more complicated than that, tho, I now realize. 1) The sort didn't *used* to be case-sensitive. I just mistakenly thought it was that way. The sorting of my subfolders, where I have some folders starting with caps, and some with lower-case, *has been* case blind. It's just that at the top level of a mail account, the "automatic" folders created by either IMAPd or Mozilla (not sure which) it sorted the "automatic" folders above the ones I created for storing my mail in. I just want this behaviour back. As all of the folders I created start with lower case (at least at the top level), I had misinterpreted this change as a case-blind vs. case-specific change, which it appears not to be. 2) I just spun up a 0.9.7 build on my BSD/OS machine, and it is the same sorting/ordering at 0.9.6 was. It may be that what I'm seeing isn't the same as this bug (varying sort order in different places), but is actually a different bug specific to the MacOS X build.
there's another bug about why this would happen on Mac OS X (see #115071), but I see this on win2k. I'll investigate.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
When verify: to check Main menu items: Messages|Copy (Move), toolbar icon: File, pop-up menus.
*** Bug 116768 has been marked as a duplicate of this bug. ***
Assignee: sspitzer → naving
Status: ASSIGNED → NEW
The problem here is that XULSortService does a 'CompareString' when it should do CompareRawSortKey. This is based on isCollationKey1 and isCollationKey2 which are always false. I need more info on how to make them true in this case. cc 'ing rjc from cvs blame.
*** Bug 116333 has been marked as a duplicate of this bug. ***
*** Bug 116947 has been marked as a duplicate of this bug. ***
*** Bug 115238 has been marked as a duplicate of this bug. ***
I heard that XULSortService calls CompareString or CompareRawSortKey based on an attribute. I don't know the detail, cc to waterson, tingley.
The XULSortService (which is used for tree sorts but not outliners), when told to sort on the property "property", will try to look for a couple of "secret" sort keys before using the actual value. First, it will query the RDF datasource for the value of "property?collation=true". If a value is found, isCollationKey[1|2] is set, and CompareRawSortKey is used. If this fails, it will look for "property?sort=true" to see if any special variation of the value exists purely for sorting (I assume an example of this is a title with a leading "The" omitted). If this is not found, the sort service queries for "property". Values of "property?sort=true" and "property" are compared using CompareString (which is also much slower than CompareRawSortKey). The rdfliner, last I checked, always uses CompareRawSortKey, which could explain the variation you're seeing. To make the XULSortService use CompareRawSortKey, you'll need to load up the datasource with "property?collation=true" arcs in addition to the normal ones. Related bugs: bug 116328 (implement collation-based sorting in nsXULOutlinerBuilder), bug 116329 (XULSortService needs to handle nsIRDFBlobs).
> If this fails, it will look for "property?sort=true" to see if any special > variation of the value exists purely for sorting (I assume an example of > this is a title with a leading "The" omitted) A good example for "property?sort=true" is removing the "Re:" from mail messages when sorting on titles.
thanks for the info. I'm on it.
*** Bug 17476 has been marked as a duplicate of this bug. ***
Created attachment 64160 [details] [diff] [review] proposed fix The fix is to add one more arc - property ?collation=true. For root/server folders return null because we do not want them to be sorted based on collation key.
can you add a comment about why it is important to return NS_RDF_NO_VALUE for servers? it sounds like the reason is so we don't sort alphabetically by name. so our datasource will be asked once for ?collation=true and when that fails, we'll get asked again about sort=true one minor style nit: if (NS_FAILED(rv)) return rv; is hard to debug, since you can't set a break point on return rv; try if (NS_FAILED(rv)) return rv; fix that and add a comment, and sr=sspitzer I think folder pane / folder datasource is the only place in mailnews where we get this right. I'll log a bug on myself to look into how the addressbook does it and how the account manager data source does it.
For the servers we are doing CompareString() (?sort=true) instead of CompareRawSortKey (?collation=true) and that works( matches the folder-pane order atleast for the tests I have done). We may have to revisit the issue for servers, I hope not. atleast non-server folders are fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
The only possible issue I see with servers is if their extended characters sort differently in RDF and msgViewNavigation.js which IIRC doesn't use CompareString. Note that the servers use a different sort order generation algorithm.
I doubt that most of us really care what the order is as long as it is consistent. For example, I don't care if folders with subfolders show at the top or are mixed in with regular folders- I just need to be able to find where I want to file a message. Case sensitive or insensitive doesn't really matter (though I do prefer case sensitivity because it lets me put unimportant folders in lower case and have them sort to the bottom- but other folks tastes vary on that)
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20020110 I can confirm that this is fixed in this build. FWIW, I *do* care what the order is, because I am concerned about my time to locate a target folder, which is best for case-insensitive and not distinguishing folders with subfolders [which is a changable status in any case].
the issues are: 1) is the folder pane order correct 2) does the file / move menu follow the folder pane order 3) does next unread navigation follow the folder pane? naving, can you investigate neils comment in http://bugzilla.mozilla.org/show_bug.cgi?id=112301#c24 Are scenarios where we aren't following the folder pane order for next unread navigation?
the issues are: 1) is the folder pane order correct yes 2) does the file / move menu follow the folder pane order yes 3) does next unread navigation follow the folder pane? I have seen some issues here, will file new bug about this. looks like we might need to do CompareRawSortKey when comparing folder keys rather than relying on js (key1 <key2) neil, for servers we are using gNameProperty that uses ?sort=true so it works ok.
navin, thanks for following up. this third issue is now bug http://bugzilla.mozilla.org/show_bug.cgi?id=119350
Re: Navin's Issues 1) ALMOST. I find a curiosity in the folder pane. If I add a new folder that should sort as *first* in the list, it appears as *second*. The add logic seems unable to insert at the head of the list. If I collapse the branch and again expand it the order is correct. 2) Yes, the File/Move menus are in the correct order (case-blind, alpha by name). 3) Moving to next unread, at last attempt is not able to actually move out of the current folder. It correctly offers to read the first unread of the next-listed folder but is not able to go there.
>1) ALMOST. I find a curiosity in the folder pane. If I add a new folder that >should sort as *first* in the list, it appears as *second*. The add logic seems >unable to insert at the head of the list. If I collapse the branch and again >expand it the order is correct. I highly suspect this to be related to bug 119504.
Great on Win 2K and Linux! On Mac OSX: In the context menu all folders are sorted in the order: first - Digits, then with underscore, then alphabetical order. The folder with sub-folders is shown last, even though it's not in alphabetical order. Special folders are mixed with General ones. I don't think it is expected sorting. Another strange thing for this Account on Mac is that in the Folder pane sorting is mostly in alphabetical order. But first one is just empty folder with name started with "u". Folder "12345" is shown as last one. Drafts, Inbox, Trash are located in alphabetical order with others. I seems that we have now broken folders sort order on Mac. We don't expect Special folders (like Inbox) mixed with General folders (like _Test) and listed just in alpabetical order. Should I log a separate bug for this and mark this one depended on that?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Bug 115071 is for the MacOSX problem.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
Thanks! Now I can verify fix on Win2K and Linux.
Status: RESOLVED → VERIFIED
*** Bug 121194 has been marked as a duplicate of this bug. ***
*** Bug 122173 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.