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

VERIFIED FIXED in mozilla0.9.8

Status

VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: olgam, Assigned: naving)

Tracking

Trunk
mozilla0.9.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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'.
(Reporter)

Updated

17 years ago
QA Contact: esther → olgam

Comment 1

17 years ago
*** Bug 115268 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

17 years ago
Updating multiple bugs. This is a valid UI issue. Would be nice to have it fixed
if time allows.

Comment 3

17 years ago
I do not believe #112301 is a duplicate.  #112301 is newly resurfaced in the
12-14-03 build!

Comment 4

17 years ago
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.

Comment 5

17 years ago
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...

Comment 6

17 years ago
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.

Comment 7

17 years ago
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
(Reporter)

Comment 9

17 years ago
When verify: to check Main menu items: Messages|Copy (Move), toolbar icon: File,
pop-up menus.
(Reporter)

Comment 10

17 years ago
*** Bug 116768 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 11

17 years ago
taking
Assignee: sspitzer → naving
Status: ASSIGNED → NEW
(Assignee)

Comment 12

17 years ago
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. ***
(Assignee)

Comment 14

17 years ago
*** Bug 116947 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

17 years ago
*** Bug 115238 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1

Comment 16

17 years ago
I heard that XULSortService calls CompareString or CompareRawSortKey based on an
attribute. I don't know the detail, cc to waterson, tingley.

Comment 17

17 years ago
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.
(Assignee)

Comment 19

17 years ago
thanks for the info. I'm on it. 
(Assignee)

Comment 20

17 years ago
*** Bug 17476 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

17 years ago
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.
(Assignee)

Comment 23

17 years ago
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: 17 years ago
Resolution: --- → FIXED

Comment 24

17 years ago
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.

Comment 25

17 years ago
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)

Comment 26

17 years ago
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?
(Assignee)

Comment 28

17 years ago
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

Comment 30

17 years ago
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.
(Assignee)

Comment 31

17 years ago
>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.
(Reporter)

Comment 32

17 years ago
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 → ---

Comment 33

17 years ago
Bug 115071 is for the MacOSX problem.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 34

17 years ago
Thanks! Now I can verify fix on Win2K and Linux.
Status: RESOLVED → VERIFIED

Comment 35

17 years ago
*** Bug 121194 has been marked as a duplicate of this bug. ***

Comment 36

17 years ago
*** 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.