Closed Bug 25014 Opened 25 years ago Closed 24 years ago

Error - Inaccessible file/directory not handled

Categories

(Core Graveyard :: Networking: FTP, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: mozilla, Assigned: dougt)

References

()

Details

(Keywords: testcase)

TO REPRODUCE:
Use Mozilla to go to ftp://ftp.netscape.com and navigate your way down to the 
directory for 4.72. Click on the twisty to list the contents of that 
directory.

WHAT HAPPENS:
Mozilla will display the spinning twisty forever. You can't stop it because the 
stop button is not enabled during FTP operations (bug 20011).

EXPECTED:
It should throw an error since there is no anonymous permission for this dir.

BUILD:
2000012415
Jud, is this some kind of Necko weirdness?
Assignee: don → valeski
Component: XPApps → Browser-General
Status: NEW → ASSIGNED
Target Milestone: M15
Moving to M16.
Target Milestone: M15 → M16
changing qa contact to jrgm@netscape.com on some random bugs
QA Contact: paulmac → jrgm
I am not able to reproduce the infinate twisty. if we hit a dir that we can't
LS, we display an empty dir. We do need to handle permission issues. dialog
throwing is probably the answer. I'm moving this to a feature request.
Summary: Inaccessible file/directory not handled?? → [RFE] Inaccessible file/directory not handled??
Target Milestone: M16 → M20
*** Bug 26365 has been marked as a duplicate of this bug. ***
See bug 37367. For what it's worth, i don't like this one tagged as RFE.
Error-handling routines and user feedback is pretty basic stuff, as valeski
writes. 

A shared popup could be used for cases where moz don't find a dir, file or
read-access. But it definately needs to conclude such an error is found and
alert user. The sooner the better ;) Fingertrouble is common and "forever
spinning things" a nuisance: User has no idea whether it's a slow connection or
moz is off to Neverneverland.
*** Bug 37367 has been marked as a duplicate of this bug. ***
*** Bug 57895 has been marked as a duplicate of this bug. ***
Sorry: 57895 is dup of 18007, not of this one.
*** Bug 60017 has been marked as a duplicate of this bug. ***
-> dougt
Assignee: valeski → dougt
Status: ASSIGNED → NEW
I dont think that this is really an RFE either.  
Blocks: 62352
Summary: [RFE] Inaccessible file/directory not handled?? → Inaccessible file/directory not handled
*** Bug 64744 has been marked as a duplicate of this bug. ***
This works for me with today's build.  Making as such.  If this still does not
work for you, please reopen.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
VERIFIED: WFM, allplats mozilla 095.
-> ftp
+testcase

I'll look into the access/permission problem as well.
Status: RESOLVED → VERIFIED
Component: Browser-General → Networking: FTP
Keywords: testcase
Summary: Inaccessible file/directory not handled → Error - Inaccessible file/directory not handled
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.