1100069 - Opening a file channel in xpcshell causes error to be logged due to nsIHandlerService::getTypeFromExtension()

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

Attachment: t.js

Opening a file channel from xpshell works, but causes the console service to report:

JavaScript error: file:///.../dist/bin/components/nsHandlerService.js, line 891: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]

Best I can tell, this error can not be suppressed.  This is an issue when using the devtools debugger to debug XPCShell code (bug 809561) as the devtools console reports it.  This error happens each time the debugger grabs the source-code for a script (which is does regularly)

Diagnosis: nsFileChannel::MakeFileInputStream() calls into nsExternalHelperAppService::GetTypeFromFile(), which ends up calling into nsIHandlerService::getTypeFromExtension().  In an XPCShell environment, this fails due to the directory service not having a "UMimTyp" entry.

Because the c++ code is calling into JS, the error is reported to the console without a reasonable way to suppress it.

Attached is a repro - just change the first line to be a valid file:// URI and run it under xpcshell.  Note also the test adds the pref "browser.dom.window.dump.enabled" - this causes the error to be dump'd as well as written to the console service making the repro easier.  When running, you will not see any exceptions but will see the "JavaScript error:" above.

bz, it seems uriloader/* is part of the docShell module which you are the owner of.  I'm wondering what you consider a reasonable fix to this?  My first thought would be to simply catch the error in getTypeFromExtension() and return an empty string, which mxr tells me should keep all callers happy.  What do you think?

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Best I can tell, this error can not be suppressed.

nsHandlerService.js could be using Components.returnCode here, no?

Past that, you could try returning empty string; I dunno how mxr can tell you much about JS callers or extension callers, but the IDL does claim that no type means empty string.  And in any case, extensions aren't running in xpcshell, so won't hit this issue.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

Attachment: 0001-Bug-1100069-have-nsIHandlerService-getTypeFromExtens.patch

(In reply to Boris Zbarsky [:bz] from comment #1)
> > Best I can tell, this error can not be suppressed.
> 
> nsHandlerService.js could be using Components.returnCode here, no?

Ah - thanks for that pointer.  Components.returnCode itself was actually broken (bug 287107) but that's fixed now.

This patch now uses Components.returnCode to NS_ERROR_NOT_AVAILABLE is (silently) returned in this case.  It should not break any existing consumers, as they were already dealing with an error from the JS exception.

bz, could you please delegate the review if you are too busy?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8534139 [details] [diff] [review]
0001-Bug-1100069-have-nsIHandlerService-getTypeFromExtens.patch

r=me

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Thanks!

https://hg.mozilla.org/integration/mozilla-inbound/rev/062c02be18be

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/062c02be18be

Comment 7

[:Paolo Amadini]

Mark, can you point to a current xpcshell test that would trigger this? I think this may regress when we land bug 1287658, on the other hand this is just console spam and landed without a test case, so it may not be important to fix.

Comment 8

[Mark Hammond [:markh] [:mhammond]]

(In reply to :Paolo Amadini from comment #7)
> Mark, can you point to a current xpcshell test that would trigger this?

IIRC, the issue what that any file:// URL from xpcshell would trigger it. For reasons I can't quite recall, the c++ IO code ended up wanting to know the mime-type of the file being opened, called into a JS implemented object which threw, and the xpcshell boundary logged the error and continued on regardless. IIRC, it only failed in xpcshell as there was some other service that wasn't available there, but is in the browser.

> I
> think this may regress when we land bug 1287658, on the other hand this is
> just console spam and landed without a test case, so it may not be important
> to fix.

Yeah, TBH I wouldn't worry too much about it.