In Bug 857765 we are unable to present users with file and line number of throw statements they issue in asynchronous callbacks in the WebRTC RTCPeerConnection API. >if (e.result == Cr.NS_ERROR_XPC_JS_THREW_JS_OBJECT) { > // Unfortunately for context, XPCWrappedJS replaces original exception. > // > // Until original file and line# are fixed, modify msg for context: > // -'Error: x' when calling method: [RTCPeerConCallback::onCallback] > // +'Error: x' when calling method: [RTCPeerConCallback::onCreateOfferError] > // > // caller ~= "PeerConnectionObserver.prototype.onCreateOfferError" A fix would seem to require converting a JS stack (Error.stack) into an XPCOM stack (nsIStackFrame) and pass that into nsXPCException::NewException. This would seem to have general value.

In general, XPCWrappedJS exception handling is totally insane and unfixable. You might try throwing |new Components.Exception| though and see if that fixes it.

Thanks, yes we use Components.Exception elsewhere, but we cannot throw in this case, because we don't want these async callbacks to take down peerconnection. So we We catch, report and continue. The errors get reported fine BTW. It's just that the filename and line numbers aren't very helpful since they don't point to the user's throw in the DOM script. This may all become moot if we fix Bug 823512.

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.