Closed Bug 1656302 Opened 4 years ago Closed 4 years ago

NS_ERROR_FAILURE: Should pass a non-null uri

Categories

(Firefox :: Address Bar, defect, P3)

defect

Tracking

()

RESOLVED FIXED
82 Branch
Tracking Status
firefox82 --- wontfix
firefox83 --- fixed

People

(Reporter: kernp25, Assigned: froydnj)

References

Details

Attachments

(2 files)

Attached image 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.

Flags: needinfo?(dao+bmo)

Marco has touched this area of the codebase most recently.

Flags: needinfo?(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...

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?

Flags: needinfo?(nfroyd)
Flags: needinfo?(mak)
Flags: needinfo?(dao+bmo)
Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

(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?

Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(continuation)

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.

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

Flags: needinfo?(continuation)

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).

Flags: needinfo?(kmaglione+bmo)
Assignee: nobody → nfroyd
Status: NEW → ASSIGNED
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/419cb80fbf03
remove interface name for URIFixup component definition; r=mccr8
Pushed by nfroyd@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/44801b6e7c7a
remove interface name for URIFixup component definition; r=mccr8
Flags: needinfo?(nfroyd)
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Regressions: 1667931
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: