Closed Bug 69134 Opened 20 years ago Closed 20 years ago
Opening nonexistant files can cause crash
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.
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
QA Contact: doronr → tever
Confirmed on WindowsME Build 2001030505 Specifying any invalid local URL seems to do the trick.
*** 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.
need to find a win98 build to verify this fix.
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.
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.
Status: RESOLVED → VERIFIED
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.