PeerConnection.js, line 558: uncaught exception: 2152398858

NEW
Unassigned

Status

()

Firefox
RSS Discovery and Preview
P5
trivial
Rank:
45
2 years ago
2 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(firefox45 affected)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8691350 [details]
testcase

JavaScript error: resource://gre/components/PeerConnection.js, line 558: uncaught exception: 2152398858

https://dxr.mozilla.org/mozilla-central/rev/d3d286102ba7f8801e9dfe12d534f49554ba50c0/dom/media/PeerConnection.js#558
2152398858 is Cr.NS_ERROR_MALFORMED_URI, which seems explicitly caught in the code linked:

      try {
        return ios.newURI(uriStr, null, null);
      } catch (e if (e.result == Cr.NS_ERROR_MALFORMED_URI)) {
        throw new this._win.DOMException(msg + " - malformed URI: " + uriStr,
                                         "SyntaxError");
      }

In fact, when I run this, I see this in web console:

  SyntaxError: RTCPeerConnection constructor passed invalid RTCConfiguration - malformed URI: pcast:javascript:5

and at the same time I see this in browser console:

  uncaught exception: 2152398858 PeerConnection.js:558:16

How is this possible, and by what definition is this uncaught?

Updated

2 years ago
backlog: --- → webrtc/webaudio+
Rank: 45
Priority: -- → P4
bz, any idea what could cause this, and/or who might know more?
Flags: needinfo?(bzbarsky)
Sure.  What's happening is that you have chrome JS (in PeerConnection.js) which calls into C++ (the newURI call).  This C++ in turn calls out into JS, because the protocol handler involved is implemented in JS.  That JS throws an exception.  That exception is not caught by that JS, gets reported when returning back into C++, propagates as an nsresult through the C++, gets turned into a new exception returning from the C++ to JS, and gets caught in the code cited in comment 1.

XPConnect used to try to guess whether to report the exception or not at that first return point from JS to C++, but the problem was that it often guessed wrong, leading to exceptions not being reported when they should be.  So I think all that gunk got ripped out and now we just always report.

Anyway, I poked in the debugger at what JS is being called from the IOService for this newURI call, and it's browser/components/feeds/FeedConverter.js line 528.  Which is the newURI function for the "feed" and "pcast" protocols; not surprising, since the URI in this testcase is "pcast:stuff".

Anyway, it might make sense to change this newURI implementation in FeedConverter to do:

  Components.returnCode = Cr.NS_ERROR_MALFORMED_URI;
  return;

instead of doing:

  throw Cr.NS_ERROR_MALFORMED_URI;

Would need testing to make sure the C++ consumer does in fact see the right nsresult in that case, of course.
Flags: needinfo?(bzbarsky)
Severity: normal → trivial
backlog: webrtc/webaudio+ → ---
Component: WebRTC: Networking → RSS Discovery and Preview
Priority: P4 → P5
Product: Core → Firefox
(Reporter)

Comment 4

2 years ago
Created attachment 8698730 [details]
testcase 2

JavaScript error: resource://app/components/FeedConverter.js, line 538: uncaught exception: 2152398858

JavaScript error: resource://app/components/FeedConverter.js, line 538: NS_ERROR_MALFORMED_URI: The URI is malformed'The URI is malformed' when calling method: [nsIProtocolHandler::newURI]

(I have the second one down as bug 949926...)
You need to log in before you can comment on or make changes to this bug.