69134 - Opening nonexistant files can cause crash.

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[Chase Tingley]

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.

Comment 1

[Chase Tingley]

Attachment: Talkback data

Comment 2

[timeless]

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

Comment 3

[Ken Snider]

Confirmed on WindowsME Build 2001030505

Specifying any invalid local URL seems to do the trick.

Comment 4

[Doug Turner (:dougt)]

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

Comment 5

[Doug Turner (:dougt)]

I can't reproduce on linux.  Looking at windows...

Comment 6

[Doug Turner (:dougt)]

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.

Comment 7

[Doug Turner (:dougt)]

Attachment: Possible fix.

Comment 8

[Doug Turner (:dougt)]

need to find a win98 build to verify this fix.

Comment 9

[Darin Fisher]

r=darin

Comment 10

[Gagan]

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

[Doug Turner (:dougt)]

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

Comment 12

[Doug Turner (:dougt)]

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

Comment 13

[Jesse Ruderman]

> The unified diff does not give much context.

That's bug 70436 :)

Comment 14

[Doug Turner (:dougt)]

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.

Comment 15

[Doug Turner (:dougt)]

.

Comment 16

[Doron Rosenberg (IBM)]

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

[Doug Turner (:dougt)]

Attachment: Patch without CR/LF

Comment 18

[Tom Everingham]

verified

Comment 19

[Darin Fisher]

in hindsight, this seems to have been an over zealous fix for this crash...
w/ IMO a potentially serious performance cost (see bug 93582).