file: enable html directory listing mode




Networking: File
16 years ago
4 years ago


(Reporter: bbaetz, Assigned: dougt)


(4 keywords)

helpwanted, intl, testcase, topembed+
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt3][se-radar])


(4 attachments, 4 obsolete attachments)



16 years ago
I checked in bug 78148, which has the backend work, but I had to disable it for
file urls because non-ascii filenames didn't display correctly. I need to poke
arround a bit and try to work out whats broken, and how to fix it.

Its surprising that the urls work, but since they do, all this involves is
probably moving the code to get the filesystem charset out of the #ifdef
THREADSAFE_I18N block, and proxying the call to get the FS charset over to the
UI thread.

I doubt I'll have time to do this in the next week, though.


16 years ago
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6

Comment 1

16 years ago
Out of time, -> 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 2

16 years ago
This has missed 0.9.7, and so moving to 0.9.9 (I'm not here for 0.9.8). Bug
102812, bug 102826, and bug 110760 will probably be fixed by the same fix, and
so nominating for 1.0, since I expect that embedders will want bug 110760 fixed,
at least.
Keywords: mozilla1.0
Target Milestone: mozilla0.9.7 → mozilla0.9.9

Comment 3

16 years ago
Will this fix bug 49944 too or not ?

Comment 4

16 years ago
Well, it won't fix it, but since it won't be using the xul viewer you won't be
able to notice it.


16 years ago
Depends on: 110760

Comment 5

16 years ago
*** Bug 115135 has been marked as a duplicate of this bug. ***

Comment 6

16 years ago
-> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 7

16 years ago
So, is the plan to hardcode this change, or have it selectable?
Summary: enable html directory listing mode for file urls → file: enable html directory listing mode

Comment 8

16 years ago
A pref.

Comment 9

16 years ago
Created attachment 73360 [details] [diff] [review]

This needs i18n testing to check that it works.

Because of other bugs (nspr ones wrt file system encoding), this can only be
tested on a non-english w2k version. Please compare file listings with a
non-english file both before and after. Check that you can follow the link as
well as see the name.

If there is a problem which applies with the patch but not without, please
save-as the file:/// directory listing page, and attach it + a screenshot to
this bug.

Comment 10

16 years ago
momoi, can I please get you to test the attached patch? See my earlier comment
for testing instructions.
Keywords: qawanted

Comment 11

16 years ago
I'm not able to do in today. Sorry for that. I'll try tomorrow.

Comment 12

16 years ago
Hmm, the patch does not work on my environment...
I'm using NT4.0 JA.

I built the binary and tried just c:\, it does not work,
nothing happened. Actually before I applied the patch,
the binary worked to display directory listing...

Comment 13

16 years ago
Do you get no display, or empty files, or something else when you do file:///c|/
? Does it just hang, or something else?

Comment 14

16 years ago
No action happens for me. Same results for file:///c|/.

When I back out the patches under netwerk/, the behavior
changed. I type "c:\" on url field and return, it changed
to "file:///c:/" on url field. But nothing is displayed.

Comment 15

16 years ago
Hmm. So it breaks even without my patch? This broke a while ago, but it was
fixed, I thought - when was your source updated?

Comment 16

16 years ago
I pick up the tar image yesterday. Without patch,
it displays directory tree properly. 

Comment 17

16 years ago
Hmm. Was this a debug or a release build? With the patch, can you try running
regxpcom before starting up?

Also, what is the setting in prefs->debug->networking? The direcroty format
should be html, but can you test with XUL also? (With my patch)

Comment 18

16 years ago
I tried both debug and optimize build.
Row and XUL seems to work for me.
Only HTML mode does not work.

Comment 19

16 years ago

Can your team also try the patch on Windows JA?

Comment 20

16 years ago
This works on linux - can I get you to step through the code I added in
nsFileChannel.cpp and see which line causes the failure? 

Comment 21

16 years ago
bbaetz: nhotta asked me to try the patch, so I quickly looked over the patch
        before I go ahead and apply it to my local tree.  
        I now see netwerk is depending on Pref.  Hmmm, we should check with 
        darin or alecf (dependencies keeper).

darin/alecf: what do you guys think?

Comment 22

16 years ago
Netowrk (http/ftp) has always depended on prefs (user agent, http version, and
so on). File didn't need it before, but this patch doesn't change what
dependancies the main necko library needs.

Comment 23

16 years ago
*** Bug 128958 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
This patch fails on windows, apparently because of a return value of
NS_ERROR_FILE_UNRECOGNIZED_PATH being returned somewhere.

Can someone with a windows machine apply this and try to work out where this is
coming from?

/me smiles at dougt and darin

Comment 25

16 years ago
Created attachment 75888 [details] [diff] [review]
resolve cvs conflicts

This just resolves some conflicts.

I'm still looking for windows people to help debug this. I can walk people
through what to debug, if they are familiar with msvc and have a debug build to
apply this patch on.
Attachment #73360 - Attachment is obsolete: true

Comment 26

16 years ago
OK, steve morse helped me debug this partly. The first problem is that GetParent
appears not to work. Ignoring the return value at line 172 of nsIndexedToHTML,
and changing the if (parent) to if (NS_SUCCEEDED(rv) && parent) makes this get
further. (Its failing to find a \ in a path which does have a \ in it, somehow).
Steve only had an opt tree, so we couldn't work out more info.

Since the current file:/// viewer doens't let you go to the parent directory,
I'm happy to change this call to ignore errors.

However, there is still a problem, in that no file actually displays. It looks
like the correct data is coming in to the parser, but it dies somewhere after
that. Steve had to go, so we didn't get any further - I don't know where it is

Any volunteers, with a debug windows tree?


16 years ago
Keywords: helpwanted, nsbeta1

Comment 27

16 years ago
bbaetz: if you find me today, i can help.

Comment 28

16 years ago
nsbeta1+, let me know if you guys need anyone else.
Keywords: nsbeta1 → nsbeta1+

Comment 29

16 years ago
Created attachment 76115 [details] [diff] [review]
patch for nsLocalFileWin.cpp

ok, so GetParent fails when called on a nsLocalFile w/ path = "c:"

w/ this patch and bbaetz's patch, i can view "file:///c:/" under win2k.

Comment 30

16 years ago
Steve was having problems with a subdir, though - that was teh first thing I
tried after c: failed. I'm wondering if he just had an old tree, or something.

Given the windows breakage, this probably needs mac checking, too - I'll see if
I can find someone to handle that, and then get i18n testing, too.

When I get home I'll attach a patch which is less strict about getparent
succeeding, though.

Comment 31

16 years ago
Created attachment 76148 [details] [diff] [review]

OK, now we don't fail if GetParent fails. We will assert, though.
Attachment #75888 - Attachment is obsolete: true

Comment 32

16 years ago
Comment on attachment 76148 [details] [diff] [review]

>Index: netwerk/protocol/file/src/nsFileChannel.cpp

>+        PRInt32 sFormat;
>+        rv = prefs->GetIntPref("network.dir.format", &sFormat);

nit: sFormat.. why the s-prefix?  the s-prefix is typically used for static
data or strings.

>+nsFileChannel::GetListFormat(PRUint32 *format) {

nit: inconsistent brace style

i think you should include the nsLocalFileWin.cpp patch.  w/o it, GetParent is
not following
the documentation for nsIFile::parent.

Attachment #76148 - Flags: superreview+

Comment 33

16 years ago
K, changed locally. Your patch is a separate bug. r=bbaetz on that.


16 years ago
Attachment #76115 - Flags: review+


16 years ago
Whiteboard: [adt3]

Comment 34

16 years ago
Comment on attachment 76115 [details] [diff] [review]
patch for nsLocalFileWin.cpp

Attachment #76115 - Flags: superreview+

Comment 35

16 years ago
Comment on attachment 76148 [details] [diff] [review]

r=darin w/ the changes i mentioned in comment #32
Attachment #76148 - Flags: review+

Comment 36

16 years ago
Created attachment 76354 [details] [diff] [review]

[darin: you gave both r and sr to that last patch - alecf's sr was for teh
separate windows one]

Mac behaves differently, so I had to copy code from the rdf:file stuff, so that
size includes the resource fork, and we handle package files correctly. I also
needed to inlcude the charset, since mac uses a different format to the default
one I assumed. See the comments for why this is done where it is.
Attachment #76148 - Attachment is obsolete: true

Comment 37

16 years ago
Created attachment 76359 [details] [diff] [review]

Now compiles on mac! And fixes a thinko with getting file sizes on non-mac.
Attachment #76354 - Attachment is obsolete: true

Comment 38

16 years ago
Comment on attachment 76359 [details] [diff] [review]

Apparently this still doesn't get the japanese file stuff working correctly. I
need to try to work out what is hapening, and where this is getting lost.
Attachment #76359 - Flags: needs-work+

Comment 39

16 years ago
OK, one more random guess: In nsIndexedToHTML.cpp, try changing the
NS_ConvertASCIItoUCS2 to NS_ConvertUTF8toUCS2, in both places.

This is a random guess, and is very likely to break something.

If this doesn't work, I have one more guess (use nsITextToSubURI + the charset

Comment 40

16 years ago
It seems that

    nsXPIDLString tmp;
	PRUnichar* escaped = nsEscapeHTML2(tmp.get(), tmp.Length());



are not working properly but title string is encoded as Shift_JIS
properly and is displayed OK.

    nsXPIDLString title;
    nsAutoString uniSpec; uniSpec.AssignWithConversion(spec);

    const PRUnichar* formatTitle[] = {

    rv = mBundle->FormatStringFromName(NS_LITERAL_STRING("DirTitle").get(),
    if (NS_FAILED(rv)) return rv;


Comment 41

16 years ago
Was that with or without the UTF8 change?

This is odd - the prtime stuff should be safe, unless its confused by the
description being wrong. If you remove the escaping, what happens?

Comment 42

16 years ago
The changes of UTF-8 did not fix the problem. Yes, I tried
not to use escaping, but it did not fix the problem.

Comment 43

16 years ago
Ok... I'll have to try to debug this, then, I guess.

Comment 44

16 years ago

OK, how about this. In nsDirIndexParser.cpp, change line 277 from:

if (gTextToSubURI) {


if (0 && gTextToSubURI) {

That will then bypass the convertions, which is what I think is causing
problems. If you do this, then spaces will display as %20. Thats OK; if this
works then I can tidy this up to just unescape normally until i18n is threadsafe.

Comment 45

16 years ago
OK, that didn't work. I could try a few more things, but the fact that the
datetime is also wrong suggests that this is probably a deeper problem.

In bug 118179, yokoyama noticed that the string input stream stuff does
ToNewCString. This could be the cause.

katakai has been of great help trying to debug this - I can't do this from here.
Unless we can work this out, or get a work arround, then this will have to be
pushed off past 1.0

Comment 46

16 years ago
Not really sure for me what we should do here... but here are the results
while I'm debuging on UNIX platform,

- nsIndexedToHTML::OnStartRequest()

    char* spec = nsCRT::strdup(baseUri.get());
    char* escaped = nsEscapeHTML(spec);

    spec and escaped are native encoding e.g. Shift_JIS or EUC.
    So I think we need to convert these to UCS2.

- nsIndexedToHTML::OnIndexAvailable()

  Who will/should convert buffer and pushBuffer to native encoding finally?
  Append() is doing as UCS2, but who will convert them to native encoding
  that specified by "charset=" field?

  Currently, it seems that \u304b\u3044 is converted to 0x4b0x44 at the

I'll put sample codes for nsIndexedToHTML.cpp, it's *not* a patch,
just an example codes.

- convert spec and escaped to native encoding to UCS2

- convert buffer and pushBuffer to native encoding
  Not sure where is the correct place to do conversion

It's working for me on Linux. Page format is not good on Window
build. but the character conversion is correct for me.

Comment 47

16 years ago
Created attachment 78156 [details] [diff] [review]
example: add conversion to UNICODE, to native encoding

Comment 48

16 years ago
Thanks a lot for this! What do you mean by 'page format is not good' - does this
means that it doesn't work on windows? In other words if I made the patch a real
patch (removing calls to exit, and so on), would that fix the problem?

Presumably if there is a charset bit in the content type, layout handles it.
Thats what I've been assuming, but I may be wrong.

Comment 49

16 years ago
My example codes around Convert() seem to be wrong...
The code conversion itself is correct and it works fine
on Linux. But source len or dest len for Convert() should
be corrected because the layout of table is broken by
the extra '<' on Windows. I'm sorry I just gathered the
codes from others. I understand if we could re-write
codes around Convert() correctly, it should work on both
Linux and Windows, I believe.

Comment 50

16 years ago
Isn't this very close to ?
darin suggests that we should change 
nsString pushBuffer 

nsCString pushBuffer

see comment
We may need to work together on this; because we could potentially collide.

Comment 51

16 years ago
right - I think we're looking at the same problem here, except that in my case
we know the charset we have, and in yours we need to guess.

This bug is wanted for 1.0, since there are usablility/perf issues with the
current xul view which were pushed off to 1.1. I can't debug this though, I
don't think.
Whiteboard: [adt3] → [adt3]se-radar

Comment 52

16 years ago
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 53

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

Comment 54

16 years ago
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+

Comment 55

16 years ago
I have a patch for 118179.
Can you try the patch in Win/Linux/Mac if it fixes this problem?


16 years ago
Keywords: topembed

Comment 56

16 years ago
>because non-ascii filenames didn't display correctly.
Well, Ja filenames in my c drive ( W2K-Ja ) show correctly
with and without my patch (118179). :(

I observed two issues here:
1) Ja _Folder Name_ diplays as a blank folder
2) None-locale filename (eg Korean filename) is vanished from the list!!

Comment 57

16 years ago
This will  apparently work on windows-ja system, but no windows-en systems,
because of the particular api calls nspr makes.

So you mean that with the patch in this bug (v5), the jp file listings work
without problems, and appear in html mode?

Comment 58

16 years ago
Sorry; but I am little confused about this bug.  The current plain vanilla trunk
displays Ja filenames correctly in W2K-ja with Pref/Networking/HTML mode 
except two problems I described in #56.

Comment 59

16 years ago
I suspect the nsifile cleanups may make this easier, since I can now get stuff
whic is definately-honestly-really utf8, I believe.

I hope to have a new patch this week.
Depends on: 129279

Comment 60

16 years ago
*** Bug 141845 has been marked as a duplicate of this bug. ***

Comment 61

16 years ago
dougt checked in something along these lines for bug 141247. It has the same
problem my patch does with non-ascii names, plus it didn't carry forward some
platform specific changes (eg for package stuff for the mac).

I hope to have this patch merged + working with the new nsIFile stuff this
weekend, if I find time. Then someone will need to test it....
Keywords: intl
Summary: file: enable html directory listing mode → file: enable html directory listing mode for non-ASCII patchs

Comment 62

16 years ago
Bradley: I am more than happy to help out.  Just give me a shout.


16 years ago
Keywords: topembed → topembed+

Comment 63

16 years ago
nsbeta1- -> nsbeta1: renominating. File is the only protocol handler using
XUL-tree. Gopher and FTP have both migrated, so the existence of file w/ tree is
actually somewhat inconsistent with the rest of the application.

Keywords: nsbeta1- → nsbeta1

Comment 64

16 years ago
We would prefer that all of these use HTML, not tree or outliner, but are way
past fixing 'inconsistency' bugs.  What is the impact of this on target users?


16 years ago
Keywords: mozilla1.0


16 years ago
Depends on: 159051


16 years ago
Blocks: 159051
No longer depends on: 159051
OS: Windows 2000 → All
Hardware: PC → All

Comment 65

16 years ago
-> default owner. I'mnot going to get to this any time soon, but I'll review
Assignee: bbaetz → dougt
Summary: file: enable html directory listing mode for non-ASCII patchs → file: enable html directory listing mode for non-ASCII paths
Target Milestone: mozilla1.0.1 → ---

Comment 66

16 years ago
I think this is fixed by bug 162377.

Comment 67

16 years ago
per last comment.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 68

16 years ago
Are you sure? I think bug 162377 just fixed html-ftp listings. I still can't get
anything but the xul listing for file://

Comment 69

16 years ago
right, it is working for HTML listing mode only
please re-open if this bug is about XUL listing

Comment 70

16 years ago
the XUL viewer is unsupported.  If there is a bug in it, please move to XPAPPs.

Comment 71

16 years ago
This bug is _NOT_ fixed. file:/// still only loads the XUL listing. Bug 162377
may make fixing this easier, but its definatley not fixed - for a start,
nsDirectoryViewer hardcodes file to the XUL format, and the patches in this bug
have not been applied.
Resolution: FIXED → ---

Comment 72

16 years ago
never mind my comment.  It was for another bug. 

Comment 73

16 years ago
Naoki may have time next week to look at this.
Assignee: dougt → nhotta
Target Milestone: --- → mozilla1.2beta

Comment 74

15 years ago
I looked at this with Roy and we saw that file:// shows Chinese file name on
Chinese system (WinXP). 
Katakai san, what is the remaining problem?

Comment 75

15 years ago
I tried Japanese case also, it works fine as long as the system default is set
to Japanese. 
The current patch uses nsIPlatformCharset which depends on the system default.
So it cannot support path names in non system default. 

Change topembed+ to topembed for re-evaluation.
Keywords: topembed+ → topembed
Target Milestone: mozilla1.2beta → ---

Comment 76

15 years ago
Change qa contact to ylong.
So far, I saw that the listing works for the default locale.
Yuying, please check if that is the case. What I tried was like file:///C:/
QA Contact: benc → ylong

Comment 77

15 years ago
Confirm it's works fine with locale non-ascii path name on all platforms with
10-09 trunk build.

Comment 78

15 years ago
Mark as worksforme.
Please reopen or file a separate bug if any remaining problems.
Last Resolved: 16 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 79

15 years ago
Mark as verified as such.
this is still a problem for ascii filepaths --but i thought this bug covered
both ascii and non-ascii.

reopening. unless there's another bug somewhere for ascii filepaths.
Resolution: WORKSFORME → ---

Comment 81

15 years ago
sairuh, what exactly is the problem?
when i try to do a local file listing, i get the XUL-formatted display, not the
HTML-formatted display.

this is what i do: for example, on linux i enter /home/halo into the urlbar,
then hit enter.

what results is the XUL listing, not an html listing. the urlbar resets what i
had entered as file:///home/halo/
comment 71 still stands, i believe. it looks like the summary morphed a bit on
the way, since it used to be something more generic, "file: enable html
directory listing mode".

Comment 84

15 years ago
Then it would be less confusing either change the summary or file a new bug.
I prefer new bug. Doug, what do you think?

Comment 85

15 years ago
Well, if this does work, then you can juat grab patch 5 and clean it up, so from
that POV I think using this bug (and remorphing back) is a good idea.

Comment 86

15 years ago
it doesn't matter: new bug or not.  all we have to do is make sure that the
default pref is set.  nhotta, can you write up a patch that does this?

Comment 87

15 years ago
dougt: Yeah, but the same pref should be used for all the directiry viewers. I
guess thats a separate bug, though.

Comment 88

15 years ago
Change the summary to "file: enable html directory listing mode" and back to
dougt for now. I can help with i18n issues.
Assignee: nhotta → dougt
Summary: file: enable html directory listing mode for non-ASCII paths → file: enable html directory listing mode


15 years ago
Keywords: topembed → topembed+

Comment 89

15 years ago
bradley, I do not understand your comment #85.  If we just enable the
preference, what are you suggesting will break without patch 5?

Comment 90

15 years ago
dougt: I'm not sure. You'd be using a different pref, so people would have ot
set both prefs. It used to be that this method required xpfe/components to do
the intermediate conversion, but that seems to have been fixed.

Comment 91

15 years ago
Created attachment 102876 [details] [diff] [review]
makes file: use the same pref as ftp and gopher

Comment 92

15 years ago
keep in mind that if I check in that last patch, the default behavior of file:
directory listings will be changed to a html listing.  

Comment 93

15 years ago
Comment on attachment 102876 [details] [diff] [review]
makes file: use the same pref as ftp and gopher


We should file a (futured) followup bug to use the same infrastructure though,
I suppose.
Attachment #102876 - Flags: review+

Comment 94

15 years ago
I will create a test build with the patch so IQA can do some i18n verification.

Comment 95

15 years ago
Comment on attachment 102876 [details] [diff] [review]
makes file: use the same pref as ftp and gopher

Attachment #102876 - Flags: superreview+
many thanks to nhotta for fwd'ing info on a test mozilla build. i ran some quick
tests on win2k, and http, ftp and file listings looked fine on win2k --all are
displayed in html. (the file listing looked pretty much like an ftp listing.)
Whiteboard: [adt3]se-radar → [adt3][se-radar]

Comment 97

15 years ago
I am going to let 1.2 ship without this fix.  I do not think that the risk is
worth it to flip the switch now.

Comment 98

15 years ago
does anyone require this for 1.2?
bryner / smfr, would this be needed if chimera moves to 1.2? (see bug 159051)
or, could we just pick out this fix and land on the branch (whether it's 1.0 or
1.2 based)?

Comment 100

15 years ago
chimera can cherry-pick this fix.

Comment 101

15 years ago
Naoki's test build:
Tested on WinXP-SC and WinME-JA, the local file is listing as html format.  If I
set browser default charset matches with OS charset, then the non-ascii path
name will diplay properly which seems like expected behavior. (before this fix,
the non-ascii path name will always display fine with UTF-8 marked, don't need
change the browser default charset).  In this test build, if I set browser
default charset as UTF-8, then non-ascii path names will disappear, but this
rarely happenes in real life though.

There is no change with ftp and http server display by this change.

Comment 102

15 years ago
>before this fix,
>the non-ascii path name will always display fine with UTF-8 marked, don't need
>change the browser default charset
the xul listing uses the system's default but not Unicode (e.g. I cannot show
Japanese file name on my English Windows2000 using the XUL listing).
For local file list, it is better to use the system's default instead of the
browser's default. Or if possible we want to use Unicode file name.
Please file that issue as a separate bug (and assign to nhotta) after the patch
is checked in.

Comment 103

15 years ago
I checked the patch into chimera's branch. Note that this required fixing bug
177059, which MachO will need for this to work.

Comment 104

15 years ago
checked in.  if regressions occur, please file new bugs.
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 105

15 years ago
filed bug 179093 - file doesn't link to or load eight bit files

this did work before the checkin.

Comment 106

15 years ago
11-08 trunk build with all platforms, the file list in html mode.

However, there are some problems were introduced:
bug 179140 filed for non-ascii folder/file names can not be display/opened in Mac.
bug 179143 filed for non-ascii folders can not be opened in windows and linux.
bug 179146 filed for use system default charset instead of browser default charset.

I'm marking this bug as verified.

Comment 107

15 years ago
I did say to test non-ascii stuff...

Comment 108

15 years ago
>bug 179140 filed for non-ascii folder/file names can not be display/opened in Mac.
>bug 179143 filed for non-ascii folders can not be opened in windows and linux.
above two bugs are the same problem caused by bug 169902 recently, now it is
fixed on the trunk

>bug 179146 filed for use system default charset instead of browser 
>default charset.
this is the expected issue (see comment #102)

Comment 109

15 years ago
This should be on by default in Mozilla trunk for 1.3.a and later, and I'll be
testing that it behaves correctly.
Keywords: qawanted → testcase
You need to log in before you can comment on or make changes to this bug.