The implementation is a bit circumvoluted, but we do need to share
options between the top-level and js/src configures, possibly with
different defaults, and to properly pass things down from one to
the other. Until we are further down the road and can actually merge
both configures, this is a necessary evil.
If a QI method throws anything other than NS_NOINTERFACE, we should just report
it and propagate NS_NOINTERFACE out to callers. And if it throws
NS_NOINTERFACE, then we already clear the pending exception in
nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject, then turn the null return
value into a C++ NS_NOINTERFACE return.
The code as it stood is a bit weird. It sets up an AutoJSAPI that takes
ownership of error reporting. Then later it also sets up an
AutoEntryScript... but keeps using the JSContext it got from the AutoJSAPI.
It's not obvious that there is any guarantee that this matches the JSContext
from the AutoEntryScript!
So we go ahead and change the things that are nominally using the
AutoEntryScript to use it JSContext and take ownership of error reporting on it
explicitly. If the JSContext is the same as that of the AutoJSAPI, then we were
getting backstopped by its taking ownership of error reporting anyway. If it's
not, we don't want to leave exceptions dangling on it.
It has no effect anyway, since it is set after including config/rules.mk
MozReview-Commit-ID: LfxwCLRl99i
--HG--
extra : rebase_source : 27c4765bf954dac71b6cad01639ad6c4fcbab5bb
The error reporting machinery will try and stringify any value you pass it, and
stringifying asserts that we don't pass magic values. Easiest solution is to
just hard code the error message, since this is a testing-only function.
--HG--
extra : rebase_source : d096a2cd2f697533279c5b33cbe5de3c5a2513a9
There are several cases to consider in terms of where exceptions might come from
here:
1) We could have an exception on the JSContext already when we set up the
AutoEntryScript. In practice this does not happen, and once this change is made
we will add an assert to that effect in AutoJSAPI::InitInternal. See bug 1112920.
2) We could have an exception thrown by the XPCCallContext constructor, but it
never does that when initialized, as here, without a JSObject*.
3) We can have an exception thrown by CallMethod itself, if the callee method
wants a JSContext or optional argc. This patch switches that to using
CheckForException, which means it will behave exactly like exceptions thrown
from the actual implementation of the method we're calling in terms of how it's
reported and whether it's rethrown to callers, if any.
4) We can have exceptions thrown various places (e.g. during argument and
retval/outparam conversions) after this point, but those are all under the scope
of the AutoScriptEvaluate, whose destructor will restore the JSContext state to whatever it
was when the AutoScriptEvaluate was created. Since the AutoScriptEvaluate goes
out of scope before the AutoEntryScript does, there will be no dangling
exception on the JSContext at that point.
5) We can have exceptions thrown by the actual method call. Those are
reported, as needed, via CheckForException, and will continue to be so reported.
So in general there are two behavior changes here:
* We now treat the "callee wants JSContext or argc" case as the same as an
exception from the callee, which is not what we used to do.
* If the object we're calling comes from an inner window whose outer window has
been torn down, we will now correctly report the exception against that inner
window. Before this patch, what happend is that we would init the
AutoEntryScript with the inner window, but FindJSContext would not find an
nsIScriptContext on it (since its outer has been torn down), so we would use
the safe JS context. Then in xpc::SystemErrorReporter we would check for a
window associated with the JSContext, not find one, check for an addon sandbox
current compartment, see we're not in one, and then use the privileged junk
scope for its error reporting. The new setup in AutoJSAPI::ReportError checks
for the current compartent being a window, which of course it is.
Because --enable-application is the current way to do things, transpose
it to configure.py, but since --enable-application=js doesn't make
sense, make it an alias of a new --enable-project option.
This only partially moves --enable-application out of old-configure.in
because there are a lot of other things intertwined with it.
Bogdan Postelnicu
Jon Coppeard
Mike Hommey
Boris Zbarsky
Luke Wagner
Jim Blandy
Mike Shal
Till Schneidereit
Heiher
Nick Fitzgerald
Terrence Cole
Hannes Verschore
Ryan VanderMeulen