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.
This is needed because blending for nsDisplayBackgroundImage items will soon
happen outside of nsDisplayBackgroundImage::Paint, it will be done by an
nsDisplayBlendMode item that wraps the nsDisplayBackgroundImage item.
MozReview-Commit-ID: 20cILOGVFEG
--HG--
extra : rebase_source : 306725c99a1cd8d450149482817b8b51bc660908
The return values from the different element search functions in searchFn
have inconsistent return types, and a null check is usually not what
we want. In order to have findElement consistently return a no such
element error, we need to do a loose false test.
This bug has affected the findElement command when using the tag
name, name, class name, link text, and partial link text selectors.
Other selectors were unaffected.
MozReview-Commit-ID: C26R3YrqKyf
--HG--
extra : rebase_source : dc723ae147b9208b4274ffc4a5338f0107ddd0ed
Sadly, this needs to be conditional to not burn builds where
MOZ_ANDROID_GCM is not defined -- such as aurora. As uplift is soon,
this will have to be relanded behind a conditional abstraction (just
like Adjust).
MozReview-Commit-ID: 80gBojadDic
We're going to use it both for background-blend-mode and for mix-blend-mode.
MozReview-Commit-ID: 6zKCDSkLspc
--HG--
extra : rebase_source : 81b4691d2b74e56c634bdf08f85636ba2abbf486