Closed Bug 1257892 Opened 4 years ago Closed 4 years ago

Fix the propagation of nsIExceptions out of JS-implemented XPCOM things

Categories

(Core :: XPConnect, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox48 --- fixed

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(1 file)

This is silly.  Say a JS-implemented XPCOM thing throws an nsIException (e.g. via throw Components.Exception(stuff)).  We land in nsXPCWrappedJSClass::CheckForException which calls XPCConvert::JSValToXPCException.

This tries to check the value for being an nsIException, but only considers XPCWrappedNatives.  So we end up taking the XPCWrappedJS codepath instead of finding our already-existing exception.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #8732238 - Flags: review?(bobbyholley) → review+
https://hg.mozilla.org/mozilla-central/rev/3cdd3f35f65e
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.