Brendan offered this as a way to punch a hole through the js layer between the xpconnect exception creator and the DOM error reporter exception consumer. Then we can change the DOM code to use that info, and fix bug 482137.
Information leaks beware. Make sure this stashed value is wrapped properly to censor information leaks.
Wrapped in what sense? I assume that we would censor it the same exact way we currently censor exceptions already in the dom error reporter, no?
Yeah. We just have to suddenly wrap where we didn't have to wrap before. Also, JSErrorReport is not going to keep the value alive. Are you sure it is rooted somewhere?
brendan hand-waved something about making sure it's rooted, yes... ;) I'm still not sure where we need where we didn't have to wrap before...
The wrapping worry would be if an exception was uncaught and the reporter was called from a different compartment. But shouldn't the exception be wrapped as it throws across compartment boundaries? I didn't hand-wave rooting, I said we need to root the thrown exception value! brendan: bz: we can extend JSErrorReport with a copy of the pending exception value (need to make sure it's rooted, via stack conservatively if possible) /be
The HTML spec just added a new argument to window.onerror: the original exception, so that .stack can be gotten from it. We can't implement that unless this bug is fixed.
4 years ago
This blocks getting stacks from JS errors, which is extremely useful for QA/Stability teams for Firefox OS, and which blocks bug 355430, so nominating for b2g.
I'll take a look at this.
4 years ago
(In reply to Gary Kwong [:gkw] [:nth10sd] (yes, still catching up on bugmail) from comment #7) > This blocks getting stacks from JS errors, which is extremely useful for > QA/Stability teams for Firefox OS, and which blocks bug 355430, so > nominating for b2g. This isn't a committed feature for 1.3, so this isn't a blocker.