Closed Bug 105135 Opened 24 years ago Closed 23 years ago

ftp sub-directory listing missing from html view of page

Categories

(Core Graveyard :: Networking: FTP, enhancement)

Product:
Core Graveyard
Component:
Networking: FTP
Platform:
x86
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: tever, Assigned: dougt)

References

(
URL
)

Details

(Whiteboard: [PDT-])

Overview Description: a single ftp sub-directory listing is missing from the html view in recent builds. Steps to Reproduce: 1.) Go to url (internal only) Actual Results: 2001-10-16-05-0.9.4/ directory not displayed 2001-10-15-10-trunk 10/15/01 11:57:00 am directory 2001-10-16-06-trunk 10/16/01 07:08:00 am directory Expected Results: there should be a directory listing for 2001-10-16-05-0.9.4/ Build Date & Platform Bug Found: winNT4, Linux rh6, mac osX 10/15 branch
WFM todays windows 2k build build (20011016)
Can you try clearing the cache?
clearing cache has no effect
I can't help unless I can reproduce this. dougt - can you repoduce this on the branch?
see comment above. I can not reproduce this.
that is strange, I can reproduce it on different platforms and at least 4 other people were commenting on seeing it in 'seamonkey-internal' today. There was a link for downloading sent out because you couldn't go through the directory listing. I wonder if the fact that both of you guys are working remotely today has any significance. Doug, I didn't try win2k but I can show it to tomorrow if you want.
Can someone who is seeing this give me a network trace (using ethereal), and the results of running ./TestProtocols -verbose ftp://whatever ? I don't have access to netscape-internal servers, so I can't fix this...
I see the problem. 201 lines that extend over the buffer boundary are disposed. see nsIndexedToHTML::OnDataAvailable. Bradley do you want to fix this, or should I? Any directory listing that has a line on the boundary should illustrate this problem. Tever, can you make us some test cases for this?
Does this happen on the trunk? Or is this branch only? A quick glance though nsDirIndexParser didn't show anything - I got rid of that old parsing code, and used the xul viewer's instead - see nsDirIndexParser on the trunk If this is branch only, and you want this fixed, then you should take this, since I don't have a branch tree (my rewrite is not suitable for the branch.)
okay, it is mine. pdt - Any ftp directory listing view via html may have missing elements. The fix is low risk (but not coded). Do we have time?
Assignee: bbaetz → dougt
Keywords: nsbranch
tever, can you try this in netscape 6.1?
tever: and, if you get time, confirm that this works on the trunk?
Doug, this does appear to have been present in 6.1. I can set up a test case but I am not sure what you mean by '201 lines ...' at the moment. Can you clear that up for me a bit. Bradley, this does not appear to be a problem in the trunk, it works fine on 10/15 tr.
hmmm ... if this exact same bug is in 6.1, IMHO we should pass on this one.
Think of '201 lines' as a url that is listed in the html. I agree with jamie. tever, please double check that 6.1 has the same behavior. If it does, this bug is going to be resolved WONTFIX.
Adding PDT for tracking, and analysis.
Whiteboard: [PDT]
this should land after pdt is done with the branch for embedding.
I've verified that Mac OS X 6.1 build and Mac OS X 10-16 branch build both show this problem.
PDT-, let's try and get it in later.
Keywords: topembed
Whiteboard: [PDT] → [PDT-]
Doug: double checked ... I still see the problem on a second machine with 6.1 (200110726)
Keywords: topembed
Whiteboard: [PDT-]
Whiteboard: [PDT-]
Keywords: nsbranch → nsbranch+, topembed
I have tested it on the last official beta of the embedded client and I don't see s problem (brent, could you check and if you it works for you please remove topembed from the bug).
I am unable to reproduce this using latest N6.2 with the following userAgent string: Mozilla/5.0 (Windows;U;Win98;en-US;rv:0.9.4)Gecko/20011019 Netscape6/6.2 I can see and access the 2001-10-16-05-0.9.4
merak, the bug is there. The chance of hitting it is not great, but the bug is there. The fix is trival.
Blocks: 107066
no patchie, no reviewie, no superreviewie, no takie. is there a r/sr patch for this?
crappe. :-) I need to give this fixed for 0.9.6. Lets see if I have time.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Keywords: topembed
bmartin, because you can not see it, doesn't mean that it isn't there.
Severity: normal → enhancement
Target Milestone: mozilla0.9.6 → Future
This bug is only on the mozilla 0.9.4 branch. The bug is that directory listings (LIST response) from the server which span a 4k internal buffer will be truncated. The result is that the user viewed entry in HTML is undefined, usually missing. Marking WONTFIX. If anyone needs this for a customer, please reopen.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I didn't realize this was fixed on the trunk. what does the patch look like?
Valeski: It was fixed by my dirviewer rewrite, which removed teh html output code, and made it use the generic parser. You don't want that patch for the branch.
VERIFIED: 0.9.4 is long gone.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.