482137 - XPConnect exceptions lose useful information by the time they get reported

Status: NEW

(Core :: XPConnect, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

This came up in bug 481552.

What happens here is that DOM code throws an error nsresult.  XPConnect creates an nsIException object (which includes the method that was called(!) the filename, line number, etc).  Then it asks the DOM error reporter for a better exception object, and gets back one that's equivalent but is missing the name of the method that was called.  Then it JS-wrapes the object and calls JS_SetPendingException with it.

Now when we go to js_ReportUncaughtException, we call js_ErrorFromException, see that it's an object not of class js_ErrorClass, and henc don't create an error report from it.  Then we go on to stringify the exception object, which dumps in the line and file information in string form, and report that string to the error console.

Issues:

1)  I'm filing this under XPConnect, since it seems like XPConnect could make
    this work if it created a js_ErrorClass object with a proper reportp.  Is
    that correct?
2)  Can/should we usefully not clobber the xpconnect exception's info about
    what method was being called?
3)  If xpconnect can't make the JS engine behave reasonably here (e.g. can't
    create js_ErrorClass objects), can we change the JS engine to somehow allow
    a callback to get the JSErrorReport from an exception object?

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This no longer matters for the DOM....