Indexed-html converter doesn't handle parent directories. When nsIFile->GetParent is called on a top level directory, the expected result is a error code returned. The converter does not handle this error condition. Patch coming up.
Created attachment 81698 [details] [diff] [review] fixes up the file: handling of top level directories
this problem manifests itself as the user not being able to visit top level directories (ie. "file://c:/")
Comment on attachment 81698 [details] [diff] [review] fixes up the file: handling of top level directories r=chak
Attachment #81698 - Flags: review+
Comment on attachment 81698 [details] [diff] [review] fixes up the file: handling of top level directories sr=darin
Checking in nsIndexedToHTML.cpp; /cvsroot/mozilla/netwerk/streamconv/converters/nsIndexedToHTML.cpp,v <-- nsIndexedToHTML.cpp new revision: 1.25; previous revision: 1.24 done
Marking FIXED since dougt checked it into the trunk Adding adt1.0.0 to get ADT's attention for 1.0 branch checkin
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
adding adt1.0.0+. After getting drivers approval, please checkin to the branch as soon as possible and add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Comment on attachment 81698 [details] [diff] [review] fixes up the file: handling of top level directories email@example.com (and asa) for drivers for branch checkin. Make sure it's in trunk too.
Attachment #81698 - Flags: approval+
Note that the expected result is that NULL is returned, but that mac/windows currently doesn't do that. See bug 102812, and the patch + discussion arround comment #30 in that bug. Maybe I should check that patch in separately, if it hasn't already been done....
Fixed checked into the Mozilla 1.0 branch for dougt bbaetz : I just saw your comment above after the checkin. Could you please address the issue you raise in Comment #9 via this bug or a separate one...thanks
how could we test this with mozilla? IS this used by ftp file listing? or something else? how about file:// ? can anyone put down a test case for this issue. reproduce procedure?
this is only for the file protocol Frank. Here is your "reproduce procedure": 1. Enable html directory listing for the file: protocol. 2. type in file://c|/ into the url bar. 3. notice that there is a html directory listing in the content window. Prior to my change, in step three you would see nothing in the content window. adding frank so that he can read my response.
Isn't the top level in windows: file:///c:/ ? When you type: file://c:/ or file://c|/, the drive letters are recognized, and "promoted" from the hostname field to the first path segement... (: or |) should be interchangable here...
We have another bug on that not working; when thats fixed, GetParent will need to be fixed too
Can someone look at #12 and #13 and clairfy what the testcase would be?
Doug: can you provide steps on how to verify this bug? I didn't think you could get HTML view for file yet.
I really want to get this cleaned up. Can someone provide a testcase? Is the problem that: file:///c:/ failed because GetParent dies when trying to figure out how to provide the: "Up to higher level directory" link? file://c:/ (two slashes) is not a valid test case, because that automatically mapped to file:///c:/ (three slahses). If so, this has been working in trunk for a while, but I can't seem to get HTML view working on the branch. Also, is this all plats, or windows-only?
mass remove verifyme requests greater than 4 months old
You need to log in before you can comment on or make changes to this bug.