677779 - xpcshell tests don't report all JS errors, like XPConnect failures during XPCOM observers

Status: RESOLVED DUPLICATE of bug 659845

(Testing :: XPCShell Harness, defect)

Description

[Gregory Szorc [:gps]]

Problem: xpcshell tests don't report all JavaScript errors, such as JavaScript exceptions thrown during execution of XPCOM-registered observers.

Expected: If an error occurs in JavaScript, xpcshell will report this in its output.

This bug is very similar to bug 657507. However, the former only tracks logging of messages to the Console Service. Unfortunately, after locally hacking up head.js to dump() all messages sent to the Console Service, I was dismayed to see that exceptions thrown in nsIObserverService JavaScript handlers were not making it there. So, this bug seems to go beyond 657507.

What's intriguing is that the Error Console in the browser DOES report the failures described above. In the case of a JavaScript observer to a nsIObserverService topic which throws an instance of my arbitrary "Error" type, we get the following in the Error Console:

Error: [Exception... "'Error: this is a test' when calling method: [nsITimerCallback::notify]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "<unknown>"  data: no]

In xpcshell tests, we don't see this at all and the process hangs (requiring a signal to terminate).

It would be great if these errors were not swallowed during execution of xpcshell tests, as it silences real failures and makes debugging extremely difficult.

Following the details at https://developer.mozilla.org/en/Exception_logging_in_JavaScript, I defined MOZ_REPORT_ALL_JS_EXCEPTIONS in my xpcshell test environment (inside runxpcshelltests.py) while observing the Console Server, and this still had no effect. Maybe I was doing it wrong?

At this point, I don't know what else to try. There is a possibility the plumbing between the standard XPCOM environment (in the browser, etc) and the xpcshell standalone binary is different, as xpcshell.cpp appears to have a lot of XPCOM management code. Who knows.

Steps to reproduce:

1) Rewire any existing function installed as an nsIObserverService observer to always throw an exception.
2) Invoke this function via the observer service
3) Witness xpcshell hang
4) Hit CTRL+C and notice the lack of any error output related to thrown exception

Comment 1

[Josh Matthews [:jdm]]

I believe this is the same problem as bug 659845 is describing.

Comment 2

[Gregory Szorc [:gps]]

This does seem like a dupe of bug 659845. Can't believe I missed it during a search before filing.