You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
This allows us to specifically whitelist browser mochitests which still rely
on unsafe CPOWs, and run them in a separate Sandbox global with permissive
CPOWs enabled.
The test harness and most of the in-tree tests will run with permissive CPOWs
disabled, like the rest of the browser.
MozReview-Commit-ID: CxIkuxr5PXJ
--HG--
extra : rebase_source : 897c951e5ea84db58e92c8b627679f029ebf4a42
This was causing problems for the test-verify mode. Sometimes the 'log' option
can contain a class instance and then 'verify' attempts to deepcopy that (which
fails).
Since the 'log' option is only used in the Mochitest constructor, it's probably
simplest to just remove it from the main options object right at the start.
MozReview-Commit-ID: 9UQAYxr2Zvm
--HG--
extra : rebase_source : e10b9419f65b0209e650de1afb5765072833d780
This is functionally a no-op but it makes code cleaner, particularly
some of the changes in a future patch.
MozReview-Commit-ID: 5UoT3aNJaPz
--HG--
extra : rebase_source : 53dbabc53ce5fbb549fa66976b41799f03be201d
We keep the XBL binding around for <content>, <constructor>, and <destructor>. This can
eventually be migrated to a Custom Element once we have platform support, but in the meantime
this is a way to get the many thousands of LOC into a JS class.
MozReview-Commit-ID: 1dCQp527yF9
--HG--
extra : rebase_source : 26b833413bab71168aa15e03f0f3803884be3f6b
extra : amend_source : 150cef6748ca8a9e819de0c674fac5966dd574cf
This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b
Pass --appname org.mozilla.geckoview.test to 'mach mochitest' or
'mach reftest'. This runs the tests without e10s currently.
MozReview-Commit-ID: 7TIvA3zRCw2
Ideally we shouldn't listen "SessionStore:update" to know the tab was removed
since closed tab information is updated in the listener of "SessionStore:update"
in browser. So it might be possible to that the listener in BrowserTestUtils
is invoked before the listener in browser.
MozReview-Commit-ID: A3S28Bmyvtw
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Most callers of EventUtils.synthesizeKey() call it only with the first argument,
aKey. Therefore, it should be optional argument.
This patch also fixes a bug of EventUtils.sendChar(). It sets shiftKey to
true even for "0" - "9" and " ". When I replace syntesizeKey() which just
type text with sendString() in the following patch, I hit this bug.
MozReview-Commit-ID: 9ndL9jLho2N
--HG--
extra : rebase_source : d9dc6bd5f9091da674f0481b4b0098694360a125
In order to facilitate testing of enterprise policies that must be applied via a JSON at startup, the path to the test data will now be made available during testing.
MozReview-Commit-ID: IUhXXsiPRYW
--HG--
extra : rebase_source : 297bff6b0bf276edfff3a1920c733c89c62b085c
extra : source : eb38c57de57a288f67156271c09bd867b1fb2643
For testing key operation stricter, all automated tests should set
KeyboardEvent.code properly. However, in most cases, automated tests
assumes that active keyboard layout is US (ANSI) keyboard layout.
Therefore, synthesizeKey() should guess KeyboardEvent.code value from
KeyboardEvent.key value as US keyboard layout automatically.
MozReview-Commit-ID: 85JyyaBwpfI
--HG--
extra : rebase_source : 8e4f3f3ac12e0dd4262813464f300dd91c996cda