Open Bug 1180876 Opened 5 years ago Updated 11 months ago

Entering a file:// URI with an invalid drive on windows causes nothing to happen


(Core :: DOM: Navigation, defect, P5)





(Reporter: Nika, Unassigned)



If you enter a file URI on windows with an invalid drive (examples: `file:///c/a/file/path` `file:///cd:/a/file/path` `file:///$:/a/file/path` etc.), into the address bar, and press enter, the current page doesn't change, and no error is reported to the user.

An error page or similar should probably be reported, as it would be relatively easy to mistype your drive, and then be very confused as you continue to stare at the page you previously had open.

This may be related to bug 1180870
Priority: -- → P5
Component: Address Bar → Document Navigation
Product: Firefox → Core

The same actually happens when you try to navigate to file:/// on Windows. So it's not necessarily a wrong drive letter.

Here a comment from bug 1495513 with some results of investigation:

(In reply to Valentin Gosu [:valentin] from bug 1495513 comment #21)

The problem seems to be coming from here:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.loadURI]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/actors/WebNavigationChild.jsm :: loadURI/< :: line 126"  data: no]
    loadURI resource://gre/actors/WebNavigationChild.jsm:126
    _wrapURIChangeCall resource://gre/actors/WebNavigationChild.jsm:63
    loadURI resource://gre/actors/WebNavigationChild.jsm:125
    receiveMessage resource://gre/actors/WebNavigationChild.jsm:43
    receiveMessage resource://gre/modules/ActorManagerChild.jsm:160

_wrapURIChangeCall in WebNavigationChild.jsm doesn't propagate the errors it gets from loadURI/LoadURIFromScript, so it just stalls. When I removed the try {} block _wrapURIChangeCall, the load failed immediately. Also, in non-e10s, loading file:/// fails immediately.

(In reply to Mike Conley (:mconley) (:⚙️) from bug 1495513 comment #23)

_wrapURIChangeCall was added in bug 1241085, but even before then we had a try/catch around the loadURIWithOptions call:

that try/catch was added in bug 798249.

You need to log in before you can comment on or make changes to this bug.