Indexed-html converter doesn't handle parent directories

RESOLVED FIXED

Status

()

RESOLVED FIXED
17 years ago
5 years ago

People

(Reporter: dougt, Assigned: dougt)

Tracking

({topembed+})

Trunk
x86
Windows 2000
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
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.
(Assignee)

Comment 1

17 years ago
Created attachment 81698 [details] [diff] [review]
fixes up the file: handling of top level directories

Comment 2

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

Comment 3

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

r=chak
Attachment #81698 - Flags: review+

Updated

17 years ago
Blocks: 141247

Updated

17 years ago
Attachment #81698 - Flags: superreview+

Comment 4

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

sr=darin
(Assignee)

Comment 5

17 years ago
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

17 years ago
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
Keywords: adt1.0.0
Resolution: --- → FIXED

Comment 7

17 years ago
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

a=rjesup@wgate.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....

Comment 10

17 years ago
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
Keywords: fixed1.0.0

Comment 11

17 years ago
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?
(Assignee)

Comment 12

17 years ago
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

17 years ago
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

Comment 15

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

Comment 16

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

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

Comment 17

16 years ago
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
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.