XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
XPCShell currently overrides all the JSContexts whose creation it observes with
its own custom error reporter. This reporter does all sorts of funny things which
we try to clean up for the most part. But there are a few very intricate
considerations at play.
First, the old xpcshell error reporter does some mumbo jumbo with the
XPCCallContext stack to try to guess whether some other code might catch the
exception. This is total garbage on a number of fronts, particularly because
the XPCCallContext stack has no concept of saved frame chains, nested event
loops, sandbox boundaries, origin boundaries, or any of the myriad of
complicating factors that determine whether or not an exception will propagate.
So we get rid of it. But this causes some crazy debugger tests to fail, because
they rely on an exception from uriloader/exthandler/nsHandlerService.js getting
squelched, and can't handle anybody reporting errors to the console service at
the particular moment of contortionism when the exception is raised. So we need
to introduce an explicit mechanism to disable the error reporter here to keep
things running.
Second, we have to be very careful about tracking the return status of the
xpcshell binary. The old code would simply flag an error code if the error
handler was invoked, and we can mostly continue to do that. But there are some
complications. See the comments.
Finally, we don't anything analogous in XPCShellEnvironment, because I have
patches in bug 889714 to remove its state-dependence on the error reporter.
I'll switch it to SystemErrorReporter in that bug.
This stuff shouldn't be necessary anymore. The default security manager should
do the right thing given for script running in the scope of a BackstagePass.
There are still a handful that either are used with other runtimes, or that
happen very early/late in cx the lifetime of various things where it doesn't
necessarily make sense to have a cx on the stack. This should definitely ensure
that we're not doing double-duty with the nsCxPusher change, though.
