For details on extensions in automation and signing, see:
https://wiki.mozilla.org/EngineeringProductivity/HowTo/SignExtensions
MozReview-Commit-ID: JL8A02zZFTH
--HG--
extra : rebase_source : 8faff1b058f48bdc7cb047d282c8c70892ab88a8
extra : amend_source : 814ab85495075824cb6fd9c43358cad3c2a798e0
extra : intermediate-source : 4fa5b5a25f04f976fdc54c03683382062a55ae37
extra : source : c664e3daa54d79fec8b9b7ea2c4bf12e2c47c7ec
For details on extensions in automation and signing, see:
https://wiki.mozilla.org/EngineeringProductivity/HowTo/SignExtensions
MozReview-Commit-ID: 6unn8eJl9PW
--HG--
extra : rebase_source : 3eb93bfa515b7b94b42c1122c1e22903638af562
extra : amend_source : 6717aff0d64992639d0ad9a5cb3c185edfbfb3f2
extra : intermediate-source : 502cf531ec266e44fdfbb1974277bf75282cf066
extra : source : 7566245cc5ea9e15415e71a2599ec72c953189df
This shows up when intercepting the reload cache type channels, since
the cache storage will reopen the cache entry that has been used to fill
up the synthesized response otherwise because of the LOAD_BYPASS_CACHE
flag.
When a built-in root certificate has its trust changed from the default value,
the platform has to essentially create a copy of it in the read/write
certificate database with the new trust settings. At that point, the desired
behavior is that the platform still considers that certificate a built-in root.
Before this patch, this would indeed happen for the duration of that run of the
platform, but as soon as it restarted, the certificate in question would only
appear to be from the read/write database, and thus was not considered a
built-in root. This patch changes the test of built-in-ness to explicitly
search the built-in certificate slot for the certificate in question. If found,
it is considered a built-in root.
MozReview-Commit-ID: HCtZpPQVEGZ
--HG--
extra : rebase_source : 898ef37459723f1d8479cfdc58658ccb00e782a9
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
Andrew Halberstadt
Ehsan Akhgari
Ben Kelly
Luke Wagner
Markus Stange
David Keeler
Boris Zbarsky
Tim Taubert
Kyle Machulis
Wilmer Paulino
Andrea Marchesini
Mike Shal
Chris Manchester
Wes Kocher
Richard Barnes
Jim Blandy
Andreas Tolfsen