Closed Bug 69134 Opened 20 years ago Closed 20 years ago

Opening nonexistant files can cause crash.

Categories

(Core :: Networking: File, defect)

x86
Windows 98
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: tingley, Assigned: dougt)

References

()

Details

(Keywords: crash)

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; 0.8) Gecko/20010214
BuildID:    2001021420

At my home page (file:///c:/ct/tech.html). The directory c:/ct contains a PDF
file, sms1000.pdf. If I try to open that file via ^O box, it prompts me for
helper app, as it should. If, however, I enter file:///c:/ct/sms1000 (note no
file extension) into the url bar and hit return, Mozilla dies a horrible death.
I was also able to trigger this by loading a .zip file from the desktop, again
by typing its name(file:///c:/windows/desktop/cdex120) into the url bar without
an extension.  If I add the ".zip", there's no problem.

Reproducible: Always
Steps to Reproduce:
Use the URL bar to open the file:// url of a local file, leaving off the file's
extension (that is, file://c:/foo/bar instead of file://c:/foo/bar.pdf).  I
believe that the file may need to be of a type that requires a helper app to
open/view.

Actual Results:  Kaboom.  

Expected Results:  Prompt to open a helper app, or simply refuse if less ambitious.
Attached file Talkback data
we should return a file not found alert. loading the file is incorrect, you can 
have thousands of files that match file:///c|/a

i think this is a dupe
Assignee: asa → dougt
Component: Browser-General → Networking: File
Keywords: crash
QA Contact: doronr → tever
Confirmed on WindowsME Build 2001030505

Specifying any invalid local URL seems to do the trick.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 72214 has been marked as a duplicate of this bug. ***
I can't reproduce on linux.  Looking at windows...
can't reproduce this crash on windows 2k either.

However, I found the possible problem for this.  The file transport does not 
check to see if the requested file exists before trying to process it.  The same 
is true for the nsFileChannel.  

I will attach a patch which will fix this.
Summary: Opening files from url bar without specifying file extension can cause crash. → Opening nonexistant files can cause crash.
Attached patch Possible fix.Splinter Review
need to find a win98 build to verify this fix.
r=darin
I may be off here... but setting mStatus to NS_OK on NS_ERROR_FILE_NOT_FOUND 
seems odd. Care to explain that?
The unified diff does not give much context.  This code is in the case of 
writing.  
*** Bug 66330 has been marked as a duplicate of this bug. ***
> The unified diff does not give much context.

That's bug 70436 :)
I checked in a possible fix to this problem, however, I don't have a win98
machine to verify this on.

Marking as fixed, looking for someone in QA to verify.
Keywords: qawanted
.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Per asa's request, win98 2001032304 - no crash by either opening a new
weblocation or directly with the urlbar. This seems fixed!

Perhaps some visual feedback would be usefull, currently it does nothing (no
popup like with a url that does not exists), but that is probably for another bug. 
verified
Status: RESOLVED → VERIFIED
Blocks: 75664
Keywords: qawanted
in hindsight, this seems to have been an over zealous fix for this crash...
w/ IMO a potentially serious performance cost (see bug 93582).
You need to log in before you can comment on or make changes to this bug.