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.
Marionette is not yet compatible with the WebDriver specification, and
we indicate this by lowering the specificationLevel capability to 0.
This lets us "gate" specification-compatible features, such as the new
element interactability algorithm.
The new interactability algorithm can be enabled by requesting the
capability specificationLevel 1.
MozReview-Commit-ID: 6wsEAsBtR6P
--HG--
extra : rebase_source : f37444470987bb782f32e190e3b5476eb139f142
Implements the WebDriver pointer-interactability algorithm described in
http://w3c.github.io/webdriver/webdriver-spec.html#dfn-interactable-element.
The specification compatible behaviour is enabled only when the client
requests the capability specificationLevel >= 0.
MozReview-Commit-ID: BP60SGj49OW
--HG--
extra : rebase_source : d84d38510e28ab5e0debce2051e336e1fd3f0f86
It has no effect anyway, since it is set after including config/rules.mk
MozReview-Commit-ID: LfxwCLRl99i
--HG--
extra : rebase_source : 27c4765bf954dac71b6cad01639ad6c4fcbab5bb
We only ever execute this in one place, so we can just have the main
action do the --regen --cachedir=. mode of operation.
MozReview-Commit-ID: Fis4YBPFjMl
--HG--
extra : rebase_source : f19ac1ad688115c0aee4bf307b72d6207512f702
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
This adds support for an SDK_FILES variable in moz.build, which creates
a FinalTargetFiles object to install files into dist/sdk/
MozReview-Commit-ID: 97a5NdbZmmD
--HG--
extra : rebase_source : ad8d521ec56fe4610437c8d2d503c545894b40c2
Using std::deque here causes problems for libc++ builds; TestTXMgr on
OSX 10.6 opt times out when libc++'d std::deque is used. Running the
test locally shows that the test process consumes gigabytes (!) of
memory and is thus reduced to swapping, rather than making any progress.
libc++'s std::deque also appears to be slightly slower in said test that
even OSX libstdc++'s std::deque. (Admittedly, this test is artificial.)
Let's sidestep the slowness of libc++'s std::deque by rewriting
nsTransactionStack to use nsDeque rather than std::deque. Not only does
this change enable OSX 10.6 tests to pass, it also makes TestTXMgr
significantly faster in opt builds: TestTXMgr is anywhere from 25-60%
faster (depending on the platform) than when using std::deque from
libstdc++ or libc++.
