1656302 - NS_ERROR_FAILURE: Should pass a non-null uri

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[kernp25]

Attachment: firefox_mmjVD87k4s.png

When i start Nightly, i see this error in browser console:
NS_ERROR_FAILURE: Should pass a non-null uri

Maybe it calls Services.uriFixup.getFixupURIInfo with an empty url at startup.

So checking the url first if it's not empty would avoid this error message at startup.

Comment 1

[Mike de Boer [:mikedeboer]]

Marco has touched this area of the codebase most recently.

Comment 2

[Marco Bonardo [:mak]]

this is already in a try catch, unfortunately some part of xpcom seems to print these exceptions to the console even if they are handled...

Comment 3

[Marco Bonardo [:mak]]

We could wrap this in an if, but I feel like we should not print an handled exception message to the console in general. Just try this in the Browser Console:
try{Services.uriFixup.getFixupURIInfo("", 0)} catch (ex) {}
on the contrary this works:
try{throw new Components.Exception("test", Cr.NS_ERROR_FAILURE);} catch (ex) {}

Nathan, do you have any idea about this, or do you know someone who could chime in?

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Marco Bonardo [:mak] from comment #3)

We could wrap this in an if, but I feel like we should not print an handled exception message to the console in general. Just try this in the Browser Console:

Nathan, do you have any idea about this, or do you know someone who could chime in?

This seems like weird behavior; maybe kmag or mccr8 knows what's going on here in the bowels of xpconnect?

Comment 5

[Andrew McCreight [:mccr8]]

It looks like Services is now implemented in C++ (thanks to bug 1464542), so the first test case is passing from JS to C++ to JS. Presumably the exception gets logged by XPConnect during one of those transitions. I'm not sure where exactly that would happen.

Comment 6

[Andrew McCreight [:mccr8]]

I tried looking around, but I'm not exactly sure where we decide to log these uncaught exceptions. It does seem odd.

Comment 7

[Kris Maglione [:kmag]]

This doesn't really have anything to do with Services being implemented in C++. It's just because the JS object that implements URIFixup gets an XPConnect wrapper, which means the error has to propagate through an XPIDL method that can only handle bare nsresult error codes. So, in order to avoid silently eating exceptions or losing error details, we just report any JS exception that hits an XPConnect boundary.

If you want to avoid that, you can just remove the interface name in the component definition, and Services.uriFixup object will just wind up as a bare JS object rather than an XPConnect wrapper (which is really the preferred behavior these days, anyway).

Comment 8

[Nathan Froyd [:froydnj]]

Attachment: Bug 1656302 - remove interface name for URIFixup component definition; r=mccr8

See https://bugzilla.mozilla.org/show_bug.cgi?id=1656302#c7 for the explanation.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/419cb80fbf03
remove interface name for URIFixup component definition; r=mccr8

Comment 10

[Atila Butkovits]

Backed out for failure at test_Services.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/2be29731a498cee02d21e8e8e8fd64c68ab56417

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=419cb80fbf037275dde508559ebe95475c30f532&searchStr=x1&selectedTaskRun=DFTX7jQTTaqT3ukdOIGKsQ.0

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=314610035&repo=autoland&lineNumber=6865

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/44801b6e7c7a
remove interface name for URIFixup component definition; r=mccr8

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/44801b6e7c7a

Comment 13

[Julien Cristau [:jcristau]]

Backed out of 82 for causing bug 1667931:
https://hg.mozilla.org/releases/mozilla-release/rev/1cb566ceabb8a2dd961fae94761f6c96dd498b4a