141235 - Indexed-html converter doesn't handle parent directories

Status: RESOLVED FIXED

(Core :: Networking: File, defect)

Description

[Doug Turner (:dougt)]

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.

Comment 1

[Doug Turner (:dougt)]

Attachment: fixes up the file: handling of top level directories

Comment 2

[Judson Valeski]

this problem manifests itself as the user not being able to visit top level
directories (ie. "file://c:/")

Comment 3

[Chak Nanga]

Comment on attachment 81698 [details] [diff] [review]
fixes up the file: handling of top level directories

r=chak

Comment 4

[Darin Fisher]

Comment on attachment 81698 [details] [diff] [review]
fixes up the file: handling of top level directories

sr=darin

Comment 5

[Doug Turner (:dougt)]

Checking in nsIndexedToHTML.cpp;
/cvsroot/mozilla/netwerk/streamconv/converters/nsIndexedToHTML.cpp,v  <-- 
nsIndexedToHTML.cpp
new revision: 1.25; previous revision: 1.24
done

Comment 6

[Chak Nanga]

Marking FIXED since dougt checked it into the trunk

Adding adt1.0.0 to get ADT's attention for 1.0 branch checkin

Comment 7

[scottputterman]

adding adt1.0.0+.  After getting drivers approval, please checkin to the branch
as soon as possible and add the fixed1.0.0 keyword.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 81698 [details] [diff] [review]
fixes up the file: handling of top level directories

a=[e-mail] (and asa) for drivers for branch checkin.  Make sure it's in
trunk too.

Comment 9

[Bradley Baetz (:bbaetz)]

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....

Comment 10

[Chak Nanga]

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

Comment 11

[Frank Tang]

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?

Comment 12

[Doug Turner (:dougt)]

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.

Comment 13

[benc]

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...

Comment 14

[Bradley Baetz (:bbaetz)]

We have another bug on that not working; when thats fixed, GetParent will need
to be fixed too

Comment 15

[benc]

Can someone look at #12 and #13 and clairfy what the testcase would be?

Comment 16

[benc]

Doug: can you provide steps on how to verify this bug?

I didn't think you could get HTML view for file yet.

Comment 17

[benc]

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?

Comment 18

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old