1227496 - PeerConnection.js, line 558: uncaught exception: 2152398858

Status: RESOLVED INACTIVE

(Firefox Graveyard :: RSS Discovery and Preview, defect, P5)

Description

[Jesse Ruderman]

Attachment: 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

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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?

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

bz, any idea what could cause this, and/or who might know more?

Comment 3

[Boris Zbarsky [: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.

Comment 4

[Jesse Ruderman]

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

Comment 5

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.