Closed Bug 112301 Opened 23 years ago Closed 23 years ago

Different sorting of Folders in the Folder pane and pop-up menu

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: olgam, Assigned: naving)

References

Details

Attachments

(1 file)

proposed fix
4.42 KB, patch
Details | Diff | Splinter Review 
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'.
QA Contact: esther → olgam
*** 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. ***
taking
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. ***
Status: NEW → ASSIGNED
Keywords: nsbeta1
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. ***
Attached patch proposed fix — — Splinter Review 
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
Closed: 23 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
Closed: 23 years ago → 23 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. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: