Loading a jar: URL which references a file which does not exist (either a jar file that doesn't exist or a nonexistent entry in a valid jarfile) fails silently. Should notify the user of the file-not-found, just as with any bad URL.

This looks like the same issue as in bug 19073, "Missing file: URL gives a blank page display", NEW, M14. Quoting from that bug: >----- Additional Comments From rpotts@netscape.com 1999-11-30 15:15 ----- >This looks like a webshell issue... Someone needs to look at the result >from OnEndDocumentLoad(...) and display an error page...

NOt a beta1 stopper--marking it M15.

Not an M15 stopper, marking M16. Gayatri, please add an expected completion date to the status white board. Thanks.

I think I should take this one now since I've changed this code around so much since Gayatri worked on it. Gayatri - take it back if you disagree.

Not critical for beta2 since we shouldn't be asking for unknown files during the startup process.

Mitch, did you fix this?

Nope. When you try to load a nonexistant jar: URL it will either spin indefinitely or print "error loading URL..." to the console, but there is no visible indication to the user.

Warren, I am reassigning some bugs which you own over to me (dougt). If you think that you will have time to address them please reassign them back to yourself. This reassignment was suggested by choffman.

Based on warren's 2000-05-04 comment, unsetting milestone.

Can we drag this bug to mozilla0.9.1? This bug encourages everyone to get away with bad chrome, missing CSS files etc etc. That means that those of us who build with files, not jars, in chrome suffer all the crashes, and waste lots of time debugging them.

resetting milestone. I will try to get to it as soon as I can...

mass move, v2. qa to me.

jar affected by lack of general error reporting.

mass moving target milestone. if there is time, i will try to pull things back in. email me if you think that this must be fixed for 0.9.2, preferably with a patch. :-)

simon, didn't you add a debug printf in case of reading a non existant file? I am seeing printfs in my debug build about errors reading files.

I think we should put a line in the JS console, in both debug and non-debug builds, if we fail to load a file (including XUL, CSS etc) from chrome. We need to also ensure that we have similar error handling code paths for the jar and non-jar case (i.e. working error reporting in both).

patches happily accepted

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

I have a working patch for this which doesn't implement comment 16's suggestion; it will be posted when bug 309296 is fixed.

Showing an error page requires that NS_ERROR_FILE_NOT_FOUND be thrown, not NS_ERROR_FILE_TARGET_DOES_NOT_EXIST; I've never been able to get an answer about what the difference between the two is. If there's no difference, we could just add it to the NS_ERROR_FILE_NOT_FOUND if in docshell (and get rid of the current error-translating that the file protocol does so it doesn't demonstrate this bug); I want confirmation that not doing this (and converting the thrown error to the one that docshell wants) is the correct thing to do. The GetPath --> GetSpec change is necessary so that loading the non-existent jar:http://foo/bar.zip!/baz displays "jar:http://foo/bar.zip!/baz" as the file that couldn't be found (as opposed to just "http://foo/bar.zip!/baz"). I think this was done for the typical case where the not-found was a file (and trimming "file://" is arguably more user-friendly); if it's not desired (or if we want a special-case if for !file.schemeIs("file")) I'd like to be told so during reviews.

Comment on attachment 232764 [details] [diff] [review] Show the error page The only documentation I see for NS_ERROR_FILE_TARGET_DOES_NOT_EXIST is that nsIFile::moveTo and copyTo throw it if the file you're moving or copying does not exist. I don't see any docs for NS_ERROR_FILE_NOT_FOUND, other than that the file:// protocol handler returns it. Given that, I think it's reasonable to just change the return value. >Index: docshell/base/nsDocShell.cpp >- aURI->GetPath(spec); >+ aURI->GetSpec(spec); How about QI to nsIFileURL? If that succeeds, get the file path. If not, then get the spec. Looks good with that done.

Per bz on IRC, comment 21 is sr=him with the changes; also, since nsResProtocolHandler QIs to nsIFileURL, we want a .schemeIs("file") check rather than a QI. Will check this in when I next have time...

Patch checked in, marking FIXED.

(In reply to comment #20) >I think this was done for the typical case where the not-found was a file (and >trimming "file://" is arguably more user-friendly); if it's not desired (or if >we want a special-case if for !file.schemeIs("file")) I'd like to be told so >during reviews. I wonder if there's a rfe filed for seeing the platform-specific file name...