Opening nonexistant files can cause crash.




18 years ago
18 years ago


(Reporter: tingley, Assigned: dougt)



Windows 98

Firefox Tracking Flags

(Not tracked)




(3 attachments)



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

Actual Results:  Kaboom.  

Expected Results:  Prompt to open a helper app, or simply refuse if less ambitious.

Comment 1

18 years ago
Created attachment 25474 [details]
Talkback data

Comment 2

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

Comment 3

18 years ago
Confirmed on WindowsME Build 2001030505

Specifying any invalid local URL seems to do the trick.


18 years ago
Ever confirmed: true

Comment 4

18 years ago
*** Bug 72214 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
I can't reproduce on linux.  Looking at windows...

Comment 6

18 years ago
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.


18 years ago
Summary: Opening files from url bar without specifying file extension can cause crash. → Opening nonexistant files can cause crash.

Comment 7

18 years ago
Created attachment 28284 [details] [diff] [review]
Possible fix.

Comment 8

18 years ago
need to find a win98 build to verify this fix.

Comment 9

18 years ago

Comment 10

18 years ago
I may be off here... but setting mStatus to NS_OK on NS_ERROR_FILE_NOT_FOUND 
seems odd. Care to explain that?

Comment 11

18 years ago
The unified diff does not give much context.  This code is in the case of 

Comment 12

18 years ago
*** Bug 66330 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
> The unified diff does not give much context.

That's bug 70436 :)

Comment 14

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

Comment 15

18 years ago
Last Resolved: 18 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. 

Comment 17

18 years ago
Created attachment 28632 [details] [diff] [review]
Patch without CR/LF

Comment 18

18 years ago


18 years ago
Blocks: 75664


18 years ago
Keywords: qawanted

Comment 19

18 years ago
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.