When viewing a html file with frames on your local hard drive and the src= points to files that don't exist, no error is dispalyed. A 404 Not Found would be displayed if it was on a server, but no error is displayed locally. IE displays an error when viewing locally. I would really like this so I can help diagnose problems in my html files more accurately. When a blank page appears, it appears as if there is something wrong in the .html file that the src points to. Thanks! I'll attach a testcase.

chnaging to HTML Frames

I believe frames is the wrong component for this bug. I would suggest "Networking:File". This happens on ANY non-existant local file, and it doesnt matter if it is in frames or not... Also, after failing to load a nonexistant local file, Mozilla seems to become unstable, and will crash ad the drop of a pin. I have not been able to attempt to load more than three non-existant files in a row without a crash. If you want to see what I mean, type in in the location bar file:///C|some/file/that/does/not/exist

Changing Summary & Component

Handing to the component owner... :) (I would have changed severity to Enhancement except for the stability comments. Perhaps this should be treated as two separate bugs?)

Nominating mozilla0.9. IE does this, and we should too by the next vendor brach point.

bug 66330 tracks the crashy-instability of trying to load a non-existant local file, so this bug can focus on the lack-of-an-error-page... but please do NOT take that as a suggestion that severity should be reduced to "enhancement" as Pollman suggests :)

As eric suggests, these are really to bugs. This one for the alert when reading a non-existant file, and 66330 for the crash. As for this one, I again agree with eric and this is a rfe. I am futuring it with helpwanted as a keyword. If anyone wants to find the place in the code to throw an alert, please submit a patch.

might it be a good idea to re-adjust the summary back to what it was originally before I barged in and distracted from this bugs original purpose with the crashy-related stuff now handled by bug 66330 ? perhaps "Viewing Local Non-existant file should display a warning" ? Would it be appropriate to mark this bug as depending on bug 66330 ?

Changed summary. Perhaps, the other bug should be dependent on this one rather than than this one dependent on the other? Also adding mozilla0.9, and nsbeta1 keywords. NE 4.x displayed a warning, IE 3.x dispalyed a warning. 9/10ths of a Mozilla should display a warning too. It wouldn't be too hard to do this.

moving keword nomination to mozilla1.0 since most likely will happen here.

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

> As for this one, I again agree with eric and this is a rfe. I disagree that this is an RFE. Silent failures are bad. HTTP URLs for non-existent files correctly responeds with a 404 error message. IE and Netscape 4.x provide error messages.

Probably depends on: bug 19073.

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

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

as a casual observer just passing through I'd just like to point out that this bug and bug 19073 really seem to be the same bug. I'm guessing he fix would be at a low enough level to provide the appropriate error feedback for both cases.

qa to me, +mostfreq Well, file URL's are one of many (just about every) protocol scheme handler that is not getting anything back from necko for non-existent files. The problem with marking this as a dupe is that that bug would have two dozen dupes that are actually different components that need to implement an error to the fix of 19073. Here's the Comm error as described in bug 91144: Netscape is unable to find the file or directory named /D:/publish/Distribution/icw/foobar.html Check the name and try again. [ OK ] DUPE REVIEW: ../file confused one person. bookmarks was entry point for another person.

necko return NS_ERROR_FILE_NOT_FOUND as the status in the onStopRequest(). Rick, Scott, where should we check for this and throw and alert??

hey doug, You might as well put this error message with all the rest :-) take a look at nsWebShell::EndPageLoad(...) in docshell/base/nsWebShell.cpp -- rick

r/sr=darin

this looks ok to me. you're sure that you don't want to include the name of the file that cannot be found in the message text? r=rpotts -- rick

I can display the URI path without too much trouble.

Rick, Darin, do I still have your approval?

go with the earlier r/sr's.

yep. r/sr=rpotts

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

It seems very wrong to me to be posing 'file not found' dialogs from webshell code. I think putting up dialogs should be the responsibility of something higher up the chain, like navigator's JS (assuming an appropriate error can be passed up). A good reason why posing dialogs here is bad is that embedders might want to alter this behaviour (e.g. do the IE-style errors-as-web-page thing), or might have a situation where missing files is a benign and ignorable error.

Never mind; webshell is not used by embedders. I still think File Not Found errors should be posed from navigator JS though.

Actually, nsWebShell *is* used by embeddors :-) This is just another example of our current 'you can't please them all' strategy toward error display... Currently, the webshell poses *all* error messages related to URL loading. Ideally, this should (and hopefully) will be moved out into one or more separate components someday... but for now, this is the mess we live in. -- rick

Fix checked in.

d

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

Was this fix just for the "src" in frames? Based on the duplicates that have been sent into the bug, I think people were looking for more general relief, like file URL's in the location bar that don't exist. The frame fix seems to work, although I thought that the checkURI features would cut these src URLs from being touched... +cc mstoltz@netscape.com

In build 2001092603 on Windows 95, If I type a non-existant local url such as file:///nowhere-in-particular in the URL bar and press enter, I get a blank page that says "<html><body></body></html>" and a popup error message saying "the file /nowhere-in-particular cannot be found. please check the location and try again" I have gotten that popup error message for ALL nonexistant local files no matter how I access them, ever since the fix for this bug was checked in.

> In build 2001092603 on Windows 95, If I type a non-existant local url such as > file:///nowhere-in-particular in the URL bar and press enter, I get a blank page > that says "<html><body></body></html>" and a popup error message saying "the > file /nowhere-in-particular cannot be found. please check the location and try > again" With yesterday's commerical build on US Win95: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20010925 Netscape6/6.2 I get the blank page that says "<html><body></body></html>", but I DO NOT get the popup.

I don't get a dialog either, I use mostly 0.9.4 milestone on my various systems right now.

<html><body></body></html> sounds like bug 57717.

This was fixed on the TRUNK!! If you try a netscape commercial build, make sure that it is using the trunk.

Silent failures are bad. Any reason not to nominate this one for nsbranch? The change looks pretty localized. This fix has been in the trunk for a month.

I think it needs to be trunk verified first :) How would you like to do that. You can use a daily mozilla trunk build...

> How would you like to do that. You can use a daily mozilla trunk build... I would, but I don't have one downloaded and from home it's painful to download over a modem. If someone else could do it this weekend, that'd be better...

Wait a minute, though, this isn't quite fixed. As a result of the fix to this bug, file: errors are displaying <html><body></body></html>. It's a bit soon to be resolving this, let alone verifying it. If we can't make the message pop up without opening a blank page (like in NS4), I suggest changing it to a full-page message like IE uses.

The empty page is bug 72679.

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

the alert and the blank page bugs are totally seperate. I am going to mark this bug fixed as it deals with the alert and passing an error code out to the docshell. If you are worried about the blank page look at 72679.

VERIFIED (trunk): I used Asa's testbed of trunk builds in all plats. The dialog comes up, quite nicely I might add. +nsbranch. I would really like to see this go away, maybe if we get a good final candidate, we can slide it into a "limbo" build... Doug: in Mozilla 0.9.4, I saw several problems: Linux: no response Mac: offers to download a file of type "Text Readme" [application/text], which then saves a zero byte file. Windows: behaves as described above. Are these conditions all fixable by a branch checkin, or should new bugs be created for each problem?

RELNOTE (NS 6.2): (if this is not plussed for the branch). If a file: URL refers to a non-existent file, Netscape/Mozilla will display "<html><body></body></html>" instead of an error message.

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

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

VERIFIED: Netscape 6.2 will ship unfixed (b/c it came off 0.9.4). It is relnoted, and verified in 0.9.5.

removing from 0.9.6 release notes.

-relnote