file:// local directory listings are sorted case-sensitively

RESOLVED DUPLICATE of bug 198754

Status

()

RESOLVED DUPLICATE of bug 198754
15 years ago
13 years ago

People

(Reporter: cpeterson, Assigned: darin.moz)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

When browsing local directory listings, such as file:///c://, the filenames are
sorted case-sensitively. For example, the directory "dell" is listed AFTER the
directory "Windows". This is surprising for typical Windows users.

This bug is related to bug 198754 ("FTP/html: Directory listings have
case-sensitive sort"). That bug is about FTP directory listings, which are
apparently sorted by the server. This bug is about local file directory
listings, which are presumably sorted by Windows or Mozilla.


Reproducible: Always

Steps to Reproduce:
1. Go to URL "c:\" or "file:///c:/"


Actual Results:  
The filenames are sorted case-sensitively. For example, the directory "dell" is
listed AFTER the directory "Windows". This is surprising for typical Windows users.

Expected Results:  
The filenames should be sorted case-insensitively. This is the standard, on
Windows at least. It is also more user-friendly.
See
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsDirectoryIndexStream.cpp#109

That Compare() call after that comment could be case-insensitive, as desired...
Perhaps it should be, dependent on OS?

Comment 2

15 years ago
Confirming on Win98. This took me by surprise too. I should also point out that
the standard on Windows is to list all subfolders before files when sorting by name.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
(Reporter)

Comment 4

13 years ago
I can still reproduce this bug in Firefox 1.5 Beta 1, just like I did in
Firebird 0.7 two years ago.

Updated

13 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

13 years ago
Just to be clear, most directory listings are generated via the same code, so whether this problem's seen with ftp or with file, it's the same bug.  :-)

*** This bug has been marked as a duplicate of 198754 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.