Bug 895774 - Fix ScriptFrameIter::computeThis with multiple compartments and contexts; r=jandem
Bug 889911 - Introduce xpc::SystemErrorReporter, roughly based on mozJSComponentLoader's error reporter. r=mrbkap
Bug 889911 - Replace mozJSLoaderErrorReporter with SystemErrorReporter and remove the former. r=mrbkap
Bug 889911 - Fix tests that unconditionally throw for things reported to the console. r=mrbkap

When we start sending everything reported to the JSErrorReporter to the console,
these tests end up getting confused by warnings.
Bug 889911 - Switch xpcshell to SystemErrorReporter with a little bit of special magic. r=mrbkap

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.
Bug 889714 - MOZ_CRASH in some unused IPC code for the sake of compile-time merge conflicts. r=me
Bug 889714 - Removed unused ShouldReportWarnings and ShouldCompoleOnly [sic] machinery. r=mrbkap

lol @ 'ShouldCompoleOnly'.
Bug 889714 - Remove unused ExitCode machinery. r=mrbkap

This stuff is cribbed from xpcshell, where it makes sense. But it doens't really
make sense in the IPC context, and doesn't appear to be used either.
Bug 889714 - Reduce the number of places where we pull |env| off cx. r=mrbkap
Bug 889714 - Stash the XPCShellEnvironment instance on the global, rather than the cx. r=mrbkap

We need to stash it somewhere, because the shell-provided JSNatives need to
access it. This solution only works for script running in the scope of the
global we create. Butthat's fine here, because we only use it for load() and
quit(), which only exist in the scope of that global.
Bug 889714 - Stop manually holding onto system JSPrincipals. r=mrbkap
Bug 889714 - Use SystemErrorReporter instead of ScriptErrorReporter. r=mrbkap

SystemErrorReporter is the new unified error reporter for everything non-dom.
In particular, it's used by the SafeJSContext, which we'll be switching to
here shortly.
Bug 889714 - Use the SafeJSContext in XPCShellEnvironment. r=mrbkap
Bug 889714 - Remove ContextCallback junk. r=mrbkap

There's no reason we should be doing this.
Bug 887334 - Remove AutoSwitchCompartment. r=luke

This thing is...yikes.
Bug 887334 - Rejigger the string manipulation in OnJSContextNew to avoid depending on being in a compartment. r=luke

The current code makes calls that assume (implicitly, via assertions) that |cx|
is in a compartment, which isn't a valid assumption going forward.
Bug 887334 - Null-check compartment() in JS_GetGlobalForScopeChain(). r=luke

cx->global() assumes a non-null compartment(). When we fix up various bugs
related to being in a compartment when we shouldn't be, we start to crash here.
Fix it.
Bug 887334 - Move faulty JSAutoRequest in initSelfHosting. r=luke

The call to JS_SetGlobalObject causes cx->compartment_ to be set to the self-
hosting global, which means that the JSAutoCompartment picks up that compartment
as the 'previous' compartment. So despite the attempt to restore things with
JS_SetGlobalObject at the end of the function, the JSAutoCompartment destructor
actually ends up leaving cx in the self-hosting global's compartment at the end
of this function. Moving the JSAutoCompartment construction above the call to
JS_SetGlobalObject fixes the problem.
Bug 887334 - Add a JSCompartment* to AutoCompartment and use it in JS_NewGlobalObject. r=luke

This gets rid of the wonky setCompartment usage in that function.
Bug 887334 - Don't rethrow in quickstubs if there's already an exception pending. r=luke