backlog: --- → webrtc/webaudio+
Priority: -- → P4
bz, any idea what could cause this, and/or who might know more?
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.
Severity: normal → trivial
backlog: webrtc/webaudio+ → ---
Component: WebRTC: Networking → RSS Discovery and Preview
Priority: P4 → P5
Product: Core → Firefox
You need to log in before you can comment on or make changes to this bug.