Closed
Bug 1257892
Opened 8 years ago
Closed 8 years ago
Fix the propagation of nsIExceptions out of JS-implemented XPCOM things
Categories
(Core :: XPConnect, defect)
Core
XPConnect
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 | ||
Comment 1•8 years ago
|
||
Attachment #8732238 -
Flags: review?(bobbyholley)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Updated•8 years ago
|
Attachment #8732238 -
Flags: review?(bobbyholley) → review+
Comment 3•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3cdd3f35f65e
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in
before you can comment on or make changes to this bug.
Description
•