740865 - nsIXMLHttpRequest.send() should not throw when trying to send to a nonexistent file:// URI

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[alta88]

in general, it is a poor api that doesn't return cleanly when it can, and it would greatly help consumers if more care were taken to ensure better error handling in xhr.

in a specific case, the following code:

 this.request = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"]
                   .createInstance(Ci.nsIXMLHttpRequest);
 this.request.onprogress = this.onProgress;
 this.request.open("GET", "file:///C:/NonexistentFile.xml", true);
 this.request.responseType = "document";
 this.request.overrideMimeType("text/xml");
 this.request.onload = this.onDownloaded;
 this.request.onerror = this.onDownloadError;
 this.request.send(null);

throws with NS_ERROR_FILE_NOT_FOUND.  either the .onerror callback, or .onload with an error .status (even a 404 could be valid) should be invoked, as these are likely already tested for by the caller.  but not a throw.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is actually necko throwing, not XHR per se.  I guess XHR _could_ pretend necko didn't throw and convert this to an error callback, but making every necko consumer do that seems strictly worse thank fixing this in Necko.  See bug 282432 and its numerous dependencies.

Comment 2

[Masatoshi Kimura [:emk]]

Looks like this is already fixed.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sure, since bug 282432 got fixed.

Comment 4

[alta88]

unfortunately, no. did anyone try the sample above; it throws for me, on the latest Tb trunk.

this.request.open("GET", "foo", true);

should not throw, but go to onerror.

Comment 5

[Masatoshi Kimura [:emk]]

Because even the latest Thunderbird is based on the very old Gecko version (17).
Fortunately it will be fixed by the next update.

Comment 6

[alta88]

ah yes, you are correct, thanks.  all tb trains use the gecko ESR version.  it doesn't seem clear when the cutover will be, though that's a problem for here.

Comment 7

[alta88]

'not' a problem for here.

Comment 8

[Magnus Melin [:mkmelin]]

Thunderbird trunk follows the tip of mozilla-central, not some old version.

I tried the testcase, and it does work for me on tb trunk (doesn't throw).

Comment 9

[alta88]

Based on comment 8 part 1, this bug is not fixed:

The following throw on windows:
file:foo
file:/
file:///foo

In firefox trunk urlbar, the string must be at least
file:///x:
where x is any drive, followed by a string.

to trigger a proper Not Found.

Comment 10

[Boris Zbarsky [:bzbarsky]]

No, this is fixed.  You'd get the same behavior if you try "http://totally bogus".  That's not about file not found, it's about a string that can't be parsed as a URI at all.

Comment 11

[alta88]

Followup Bug 875783 for "string that can't be parsed".