238257 - File URLs don't respect XUL directory listing format preference

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[[e-mail]]

Steps to reproduce problem:
1. Edit->Preferences->Debug->Networking
2. Change the Directory Listing Format to XUL
3. Restart Mozilla
4. Browse to file:/// or whatever applies to your platform, e.g. file:///C:/

Expected results: XUL tree-based directory

Actual results: HTML directory listing

Comment 1

[[e-mail]]

Attachment: Proposed patch

Seems like the channel should support nsIDirectoryListing anyway...

Comment 2

[Bradley Baetz (:bbaetz)]

You can't do this. To be locale safe, you need to go through intl. And intl
isn't threadsafe, or at least it never used to be.
Or something like that - I can't really rememebr the details from 2.5 years ago.

Try this on a chinese windows version, or something along those lines.

Comment 3

[[e-mail]]

Excuse me, but the patch has nothing to do with intl or locale, it's just moving
the preference from the protocol to the channel...

Comment 4

[Bradley Baetz (:bbaetz)]

Right, but you're changing which thread this all happens on, by doing this. This
way, it happens from a callback on the file io thread, rather than doing is
separately in the main thread. I think.

don't you get assertions in a debug build with this?

Comment 5

[[e-mail]]

Actually the patch just copies nsFTP/GopherChannel/ProtocolHandler :-P

Comment 6

[Bradley Baetz (:bbaetz)]

Yes, but file IO happens on a separate thread to the rest of necko. Or at least
it did 2.5 years ago... See bug 99382.

Darin?

Maybe I should try this out and try to break it. Or maybe its already broken
from an intl point of view anyway.

Comment 7

[[e-mail]]

bbaetz, perhaps you can start by explaining how the FTP/Gopher code is wrong?

Comment 8

[Bradley Baetz (:bbaetz)]

Its not wrong. The issue is that FTP/Gopher/etc happens on the necko thread. For
file, the actions are proxied out to another thread, which causes teh generation
of the data to happen on a different thread to the processing of it, causing
these issues

I will confirm this this evening (my time)

Comment 9

[[e-mail]]

I think this happens before any data is generated... SetListFormat is called
before DoChannelLoad is.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

um, doesn't all interaction with channels happen on the same thread, namely the
UI thread?

Comment 11

[Darin Fisher]

bbaetz: the only non-UI thread code is the code in nsDirectoryIndexStream.cpp,
and currently we have ifdef'd out all the unicode conversion and collation code.
 the http-index-format stream will contain filenames in the charset of the
"native" filesystem charset.  it appears that nsIndexedToHTML.cpp utilizes
nsITextToSubURI to convert to unicode strings.  so, modulo the collation bugs,
we should end up with HTML that shows file names properly.  looking over the
nsDirectoryViewer.cpp code, it appears that it does not do any similar unicode
conversion.  instead, it just does an AssignWithConversion.  IOW, it seems to
assume that all filenames are ASCII.

the directory listing format is anyways a hidden pref.  the XUL directory viewer
is an unfinished (broken) piece of code.  there also isn't an owner for it AFAIK.

ultimately, i want to do away with the way directory listings are handled.  i
think that necko should always just generate http-index-format for directories.
 at the uriloader level we should either invoke the indexed-to-html stream
converter or we should invoke a content handler for http-index-format.  the pref
should be honored at that level instead.

that said, i'm mostly ok with this patch.

Comment 12

[Bradley Baetz (:bbaetz)]

Hmm. OK. That must have changed in the last couple of years. No objection from
me, then.

Comment 13

[benc]

*** Bug 201672 has been marked as a duplicate of this bug. ***

Comment 14

[[e-mail]]

Fix checked in.

Comment 15

[benc]

V/fixed.

1.53	neil%parkwaycc.co.uk	2004-04-12 15:31	 	Bug 238257 File URLs aren't
respecting user network.dir.format pref r/sr=darin