991595 - "Call to xpconnect wrapped JSObject produced this error" should cause test failures

Status: NEW

(Testing :: General, defect)

Comment 1

[David Teller [:Yoric] - still alive but not very active]

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?

Comment 2

[(not currently active) Ted Mielczarek]

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.

Comment 3

[Ed Morley [:emorley]]

I like the idea of catching this - though I'm not sure of the best way to handle it in the harness/platform.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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?

Comment 5

[David Teller [:Yoric] - still alive but not very active]

Fwiw, Promise.jsm exposes a notification API to observe uncaught errors and we plug into this API with the test suite.

Comment 6

[Bobby Holley (:bholley)]

(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.

Comment 7

[Peter Kehl]

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

[Peter Kehl]

Attachment: test.xul

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).