Open
Bug 991595
Opened 10 years ago
Updated 2 years ago
"Call to xpconnect wrapped JSObject produced this error" should cause test failures
Categories
(Testing :: General, defect)
Testing
General
Tracking
(Not tracked)
NEW
People
(Reporter: Yoric, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
4.24 KB,
application/vnd.mozilla.xul+xml
|
Details |
No description provided.
Reporter | ||
Comment 1•10 years ago
|
||
As far as I can tell, every instance of "Call to xpconnect wrapped JSObject produced this error" represents a bug, at the very least a forgotten try/catch. To turn these into oranges, I can see the following techniques: 1. we could adapt the test harnesses to parse that specific error message; 2. we could broadcast a notification "xpconnect-jsobject-error" with the error number, file name, line number (ideally a full stack) and adapt the harnesses to receive these notifications and cause failures. Any other idea?
Flags: needinfo?(wmccloskey)
Flags: needinfo?(ted)
Flags: needinfo?(emorley)
Comment 2•10 years ago
|
||
Another plausible solution would be to add an API to get a callback when an unhandled exception happens, which would be similar in spirit to an observer service notification. Either way sounds like we probably need platform support to handle this properly.
Flags: needinfo?(ted)
Comment 3•10 years ago
|
||
I like the idea of catching this - though I'm not sure of the best way to handle it in the harness/platform.
Flags: needinfo?(emorley)
I think it would be great to have some sort of service where we centralize reporting of errors in chrome code. From there, we could decide to print it to stderr or to the error console, or we could cause tests to fail. There are a bunch of places throughout gecko where stuff like this happens (although the one in xpconnect is probably the trickiest). Bobby, is this code part of the rewrite of exceptions that you're planning?
Flags: needinfo?(wmccloskey) → needinfo?(bobbyholley)
Reporter | ||
Comment 5•10 years ago
|
||
Fwiw, Promise.jsm exposes a notification API to observe uncaught errors and we plug into this API with the test suite.
Comment 6•10 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #4) > I think it would be great to have some sort of service where we centralize > reporting of errors in chrome code. From there, we could decide to print it > to stderr or to the error console, or we could cause tests to fail. There > are a bunch of places throughout gecko where stuff like this happens > (although the one in xpconnect is probably the trickiest). > > Bobby, is this code part of the rewrite of exceptions that you're planning? Fixing that code is a pre-requisite to doing anything smart here, I think.
Flags: needinfo?(bobbyholley)
Comment 7•10 years ago
|
||
I've got an XUL with a JS bug that also generates 'Call to xpconnect wrapped JSObject produced this error'. That message only shows up in shell where I start Firefox binary from. It doesn't show up in Browser Console. That is annoying. So I'm for Bobby's comment: please centralize error reporting. I'm attaching a semi-test case (an XUL with a tree). The bug shows up when you edit a tree cell (from its setCellText handler). That's in Firefox 32.0.2 on Fedora 20x64.
Comment 8•10 years ago
|
||
Open, edit a cell, hit enter. Then it generates an error that is only printed in shell where I started Firefox binary from, but it doesn't show up in Browser Console (nor in Web Console).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•