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.
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.
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.
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.
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.
Some of this existing code is little wacky in that it calls Environment(mCx)
in a non-static method, which I would think would be equivalent to |this|.
But I don't know this code well enough to be sure of that, so I'm just going
to do the careful thing.
There is no reason to have special methods for specific sets of CompileOptions
when the JS::Compile interface is so easy to use. Other API methods can be
moved internal or removed entirely with this change.
We have many CESU8 paths in SpiderMonkey which are completely unused and
untested. We have many more "UTF-8" paths which are really mislabled CESU8 paths
and visa-versa. This patch attempts to disentable all of the various encoding
options in SpiderMonkey.
There's no longer any reason why "certificate principals" need to be principals at all.
I tried to rip them out entirely, but it looks like they're still used vestigially at XPI
install time to display author information. But there's no reason that they have to be
porkbarreled into the security-critical objects that we pass around all over the place.
So let's make them their own deal.
I was tempted to call them "certificate holders", but that would involve renaming methods and
cause more compat fuss than necessary.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
