This only includes functions that seem to be using it to reference a window.
There are other instances where it's used as a generic chrome URI, and those
are left unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D3806
--HG--
extra : moz-landing-system : lando
Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
This patch changes the failure condition of all mochitest tests to take the number of failures (given by self.countfail). It also adds a condition to check if there are passing and todo counts, and if there are not, the test chunk fails. With this change, mochitest test chunks will fail if the failure count is not 0, or all the counts (pass, todo, and fail) are 0. This fixes a case where the TODO tests were considered as failures when no passing tests were run along side them.
Differential Revision: https://phabricator.services.mozilla.com/D3612
--HG--
extra : moz-landing-system : lando
This patch changes the failure condition of all mochitest tests to only take the number of failures (given by self.countfail) into account. With this change, mochitest test chunks will only fail if the failure count is not 0. This fixes a case where the TODO tests were considered as failures when no passing tests were run along side them.
Differential Revision: https://phabricator.services.mozilla.com/D3340
--HG--
extra : moz-landing-system : lando
Catch the exception if adb pull fails on code coverage file, to avoid task retry.
Differential Revision: https://phabricator.services.mozilla.com/D3503
--HG--
extra : moz-landing-system : lando
This patch adopts Logger#managerLevelFromPref from Log.jsm to set
and keep track of the Marionette logger's verbosity.
This has the advantage that we do not have to roll separate
implementations of Log for the child- and parent processes. It also
has the upside that the log level will be reflected when changed
at runtime through the use of an observer.
With the new loading model for frame scripts, lexical variables defined in a
global frame script are not available to other frame scripts.
Additionally, scripts loaded into a context object by the subscript loader
should not depend on being able to access properties of the message manager as
if they were globals.
MozReview-Commit-ID: 6QEyA1sBVOV
--HG--
extra : rebase_source : d3a7820104645dc356bdf8ea660b970e1f6c20e7
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : 251574d238ded31b9df32dc89852251831d55757
extra : source : c53c7b0249ad3359fbc9f144f2cf9ca3b6386c59
Loading SpecialPowers into frame scripts has side-effects, detailed in part 1,
which are undesirable. The main side-effect that I'm trying to get rid of here
is the force-enabling of permissive COWs in frame script scopes, which is
blocking changes that I need to make elsewhere. But both that and the scope
pollution it causes are likely to allow code to work when running in
automation which fails in real world usage.
This patch changes our special powers frame scripts to load specialpowers.js
and specialpowersAPI.js as JSMs, which run in their own global, but define
most of the same properties on our frame script globals.
Most other callers still load those scripts via <script> tags or the subscript
loader, and should ideally migrated in a follow-up. But even so, this patch
still gives us a cleaner separation of the frame script and non-frame-script
loading code.
MozReview-Commit-ID: CR226gCDaGY
--HG--
extra : rebase_source : fa253abde2029ec09c724404106d83623f064875
This patch makes a new baseline coverage test for browser-chrome which makes use of the BrowserTestUtils functions. It also begins the necessary changes so that the baseline test addition uses suites instead of file types.
MozReview-Commit-ID: 7nucHnF8CIn
--HG--
extra : rebase_source : a2a8f61bbbc5025544bebd74cee2a06d46f23fe2
This is another quick-and-dirty port. Some of the test logic could
probably be moved to unprivileged extension code but there's no urgent
reason to do that right now.
MozReview-Commit-ID: Af0XQbakLsx
--HG--
rename : testing/mochitest/bootstrap.js => testing/mochitest/api.js
extra : rebase_source : 3870a63d96c0b2d73ccc468393c75e17b884383f
extra : source : 604167986098726b86ea0f9252a63abab36d35c4
beforeTestSync uses an asynchronous operation that takes a while to finish.
In the meantime, it's very likely that the browser will run some tasks
scheduled to run when idle, which cause XPCOMUtils mock in browser-test.js
to be used, which references _globalProperties.
--HG--
extra : rebase_source : 3d75068a43cad4e87317792c67b6fe5fd483f0c5
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
This patch adds new functions taking the arena parameter rather than overloading
existing functions, because there are already overloads of calloc that take
two size_t parameters (which arena_id_t is an alias for), so it couldn't have
been done that way, and malloc and realloc needed to be consistent with calloc.
MozReview-Commit-ID: 1MUXoCUgJWO
--HG--
extra : rebase_source : 16261ba4e802efa0bc65878d490ae9b62aa35797
This is another quick-and-dirty port. Some of the test logic could
probably be moved to unprivileged extension code but there's no urgent
reason to do that right now.
MozReview-Commit-ID: Af0XQbakLsx
--HG--
rename : testing/mochitest/bootstrap.js => testing/mochitest/api.js
extra : rebase_source : 17f8af667e73555bd69391d3be0835c3e50c90cd
Currently mochitest looks for a test_start log action and stores the name of
the test in an instance variable. In the event of a timeout/hang, this string
is used in the log to help people try and narrow down where it happened.
However, there are a couple cases it can be misleading:
1) If the hang happens during shutdown, it looks like it was the last test's fault (it probably isn't)
2) If the hang happens in-between tests, it looks like the test timed out
We should make the string more descriptive. I propose that when we get a
test_end action, we change it to <test> (finished). And when we get the test
end action of the last test, we change it to "Last test finished".
This way it narrows down where the hang happened even further.
MozReview-Commit-ID: B6g8JrIJuJw
Differential Revision: https://phabricator.services.mozilla.com/D1885
--HG--
extra : moz-landing-system : lando
This patch adds a 30 second delay to the baseline coverage tests to help stabilize their code coverage results over time.
MozReview-Commit-ID: C3StSX7RdM9
--HG--
extra : rebase_source : d4ab053d0d55535333989294973aa4af7db4fea7
Summary:
This moves the load of favicons into the content process. We use the same logic
for finding favicons (based on waiting until none have shown up for a short
time) but then load the favicon and convert it to a data uri which we then
dispatch to the parent process. Along the way this fixes asssociating the load
with the tab for WebExtension and devtools, fixes CSP usage for the load, fixes
expiry detection of the favicon and stops us from loading the same resource
twice.
This change also merges the prefs browser.chrome.site_icons and
browser.chrome.favicons leaving just the former controlling favicon loading. It
adds the pref browser.chrome.guess_favicon to allow disabling guessing where
a favicon might be located for a site (at <hostname>/favicon.ico). This is
mainly to allow disabling this in tests where those additional yet automatic
requests are uninteresting for the test.
There are multiple clean-ups that can follow this but this is a first step along
that path.
MozReview-Commit-ID: E0Cs59UnxaF
Reviewers: mak
Tags: #secure-revision
Bug #: 1453751
Differential Revision: https://phabricator.services.mozilla.com/D1672
Differential Revision: https://phabricator.services.mozilla.com/D1673
Differential Revision: https://phabricator.services.mozilla.com/D1674
Differential Revision: https://phabricator.services.mozilla.com/D1850
Differential Revision: https://phabricator.services.mozilla.com/D1869
--HG--
rename : browser/base/content/test/general/browser_bug408415.js => browser/base/content/test/favicons/browser_bug408415.js
rename : browser/base/content/test/general/browser_bug550565.js => browser/base/content/test/favicons/browser_bug550565.js
rename : browser/base/content/test/general/browser_favicon_change.js => browser/base/content/test/favicons/browser_favicon_change.js
rename : browser/base/content/test/general/browser_favicon_change_not_in_document.js => browser/base/content/test/favicons/browser_favicon_change_not_in_document.js
rename : browser/base/content/test/general/browser_subframe_favicons_not_used.js => browser/base/content/test/favicons/browser_subframe_favicons_not_used.js
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon1.ico
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_bug970276_favicon2.ico
rename : browser/base/content/test/general/file_bug970276_popup1.html => browser/base/content/test/favicons/file_bug970276_popup1.html
rename : browser/base/content/test/general/file_bug970276_popup2.html => browser/base/content/test/favicons/file_bug970276_popup2.html
rename : browser/base/content/test/general/file_favicon_change.html => browser/base/content/test/favicons/file_favicon_change.html
rename : browser/base/content/test/general/file_favicon_change_not_in_document.html => browser/base/content/test/favicons/file_favicon_change_not_in_document.html
rename : browser/base/content/test/general/file_bug970276_favicon1.ico => browser/base/content/test/favicons/file_generic_favicon.ico
rename : browser/base/content/test/general/file_with_favicon.html => browser/base/content/test/favicons/file_with_favicon.html
extra : rebase_source : 6372b2681a59d267f966e9fa2ca9a54e3ff0cea0
extra : intermediate-source : b11aa832c41ac5beef9065f804d11fb7c9887990
extra : source : 638eb8a41245f6d9932861afda21edd5e0b2618a
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Users can emulate AltGr key with pressing both Ctrl key and Alt key on Windows
since AltGr is represented as so in Windows and physical keyboard may not have
AltRight key.
If user emulates AltGr key, we should set MODIFIER_ALTGRAPH to a set of
keyboard events for printable keys only when the key press produces
character(s) or a dead key. For example:
1. ControlLeft keydown event should make ctrlKey true.
2. AltLeft keydown event should make altKey true (not AltGraph state).
3. ctrlKey and altKey of printable keydown, keypress and keyup events should be
set to false, but getModifierState("AltGraph") should return true.
4. AltLeft keyup event should make altKey false.
5. ControlLeft keyup event should make ctrlKey false.
(If AltLeft key is pressed first, altKey of AltLeft keydown is true and
both altKey and ctrlKey of the following ControlLeft keydown are true as
usual.)
MozReview-Commit-ID: 8Km8GXPDQw1
--HG--
extra : rebase_source : f4924f075c68361c8ce563910280ea24774c519f
By the proposal from Google, <https://github.com/w3c/uievents/issues/147>,
Chromium treat AltRight key as "AltGraph" modifier if the keyboard layout
has AltGr key.
When AltRight key is pressed with a keyboard layout which has AltGr key,
modifiers should as following:
1. "keydown" for ControlLeft:
ctrlKey: true, altKey: false, getModifierState("AltGraph"): false
2. "keydown" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
3. Some "keydown", "keypress" and "keyup" events:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
4. "keyup" for ControlLeft:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
5. "keyup" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): false
So, only when the preceding "keydown" event for ControlLeft, ctrlKey should
be set to true as usual. However, after AltRight key is pressed actually,
we should treat "AltGraph" modifier is true and both ctrlKey and altKey
should be set to false for web apps can handle text input normally.
So, MODIFIER_ALTGRAPH and MODIFIER_CONTROL/MODIFIER_ALT should not be set
at the same time.
This patch makes ModifierKeyState have only MODIFIER_ALTGRAPH or
MODIFIER_CONTROL/MODIFIER_ALT.
Additionally, this patch makes VirtualKey::ShiftState treat "AltGraph" as a
modifier. So, now, VirtualKey needs to convert ShiftState to index value when
it accesses its mShiftStates array. Therefore, this patch adds
VirtualKey::ToIndex() and make each VirtualKey method use it before
accessing mShiftStates.
Note that this patch also fixes bug of WinUtils::SetupKeyModifiersSequence().
The constructor of KeyPair takes 2 keycode values, but the second virtual
keycode can have scancode to distinguish if the key is left or right.
However, WinUtils::SetupKeyModifiersSequence() never sets scancode to
KeyPair. Therefore, it fails to dispatch AltRight key event.
MozReview-Commit-ID: 7ealxJH9KlZ
--HG--
extra : rebase_source : 761bc4416222def020a0731d6ae7940ef074ebe0
Also removes the stub workerbootstrap extensions, which previously allowed
this to work for Mochitest extensions.
MozReview-Commit-ID: LPlk8qIgJmr
--HG--
extra : rebase_source : 329f7fe11dde7a2713652591ac735b0d745070c8
extra : amend_source : 125481f030980c610217a9a1f6e51d592bda3c65
This also removes the workerbootstrap test extension, which is no longer used,
and contains the last references to the Worker and ChromeWorker bootstrap
globals.
MozReview-Commit-ID: 8YWReXMqX5W
--HG--
extra : rebase_source : b0aa59b2b5e6a08f4be803e828bd507f894e4a19
The tests added in this patch will be used as a baseline for coverage that is common to all tests. They are added to each chunk being run in the test-coverage suite only if a test with an associated baseline type exists.
MozReview-Commit-ID: 1CrRZ1Ev2Mz
--HG--
extra : rebase_source : e2e4f9a51c82c637c8892dd8a5dbd84704b67b54
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
This serves two purposes:
1) It makes web-platform-tests pref downloading/handling a little more robust. When
run externally, it now downloads the entire testing/profiles directory. When loading
prefs it will look for both prefs_general.js (to support older versions of Firefox)
and profiles.json (for support moving forward).
This way we can add/remove/rename pref files under these directories without needing
to worry about breaking upstream wpt.
2) It provides developers an overview of which harnesses are using which base profiles.
Instead of hunting through test harness code to find this information, they can glance
at profiles.json.
MozReview-Commit-ID: AMzdnD8aGA2
--HG--
extra : rebase_source : 6fa0a802680417e49fcef99f3d03de7458a8fcba
This makes mochitest use mozprofile's new 'merge' feature instead of
explicitly loading the user.js preference file.
This means that any extensions that get dropped into
testing/profiles/common/extensions, will automatically run as part of the
mochitest run. This can be useful for testing how extensions impact tests
locally or on try.
In the near future, all our other test harnesses will also start using this
profile directory.
MozReview-Commit-ID: 34aSqdnkHqx
--HG--
extra : rebase_source : 977b0eb6404648e387428004ec3f3085af6f86fd
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 72a4a4b691e93c77479c7e70647b0ca373862c51
This commit also removes "DEFAULT_APP", which is unused.
MozReview-Commit-ID: 5YYaC5LJqUn
--HG--
extra : rebase_source : 45f0f8f11698890fae0dcca71174f88dbdb412c8
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
(This also fixes Bug 879740 and Bug 1204543.)
build/pgo/certs contains an NSS database set that has a bunch of hand-generated
certificates, and many of these hand-generated certificates are specifically
depended upon for a variety of unit tests. This patch changes all of these to
use the "pycert.py" and "pykey.py" utilities that produce deterministic keys
and certificates.
The naming convention here is new, and defined in the README. It is based on
the mochitest runtest.py naming convention that imports .ca and .client
PEM-encoded certificates.
Unfortunately, the updates to build/pgo/genpgocert.py to generate these files
depends on OpenSSL in order to produce PKCS12 archives for pk11tool to import
into NSS. This could be done with pure-NSS tooling, but it'd require some new
command line functionality, which is out-of-scope for this change.
Note that build/pgo/genpgocert.py no longer takes arguments when run. It's not
run automatically anywhere that I can see, but could (reasonably) be, now.
Differential Revision: https://phabricator.services.mozilla.com/D971
--HG--
extra : amend_source : bc389b9b0a807a4889feb14db439daa28635dfe9
The old name no longer makes sense, since it no longer exports an spawn_task
symbol, and add_task is what we really care about.
MozReview-Commit-ID: IE7B8Czv8DH
--HG--
rename : testing/mochitest/tests/SimpleTest/SpawnTask.js => testing/mochitest/tests/SimpleTest/AddTask.js
extra : rebase_source : 03bca5aa69a7625a49b4455a6c96ce4c59de3a5a
Now that Task.jsm is deprecated and add_task no longer accepts generators, it
doesn't make sense to continue making this automatically available in test
scopes.
MozReview-Commit-ID: AckO5nnFngG
--HG--
extra : rebase_source : 826b7cce67d9ab000d6385663c543bc72eef174b
This was done using the script at:
bc5629735d/processors/add-task-async.jsm?at=default&fileviewer=file-view-default
MozReview-Commit-ID: KxuS9Cen87
--HG--
extra : rebase_source : c0028e0cd55ba1643610cd30c55c6f4bca7d6e58
extra : histedit_source : ebc84fdec9c2db6176632d62de4e7bdad2a7829d
Without using "new Error()" there will always be line 0 referenced
in the exception message.
MozReview-Commit-ID: KGzVDShiLTW
--HG--
extra : rebase_source : e677730f0dcde896157681925f169da529939cf8
This makes the changes necessary to use TestRunnerActivity when geckoview
is installed and requested, but we do not yet attempt to run any such
test tasks in automation.
On desktop use sub script loader during bootstrap instead of the overlay.
On android use a component that listens for browser windows to be created
and then use a sub script loader.
MozReview-Commit-ID: Knj5OdVNEMA
--HG--
extra : rebase_source : 424fd867edf7a3ab33cede88d2066291516de10c
This sets verbose=True (used by the mach formatter) and compact=False (used by tbplformatter) if
only a single test is specified with either |mach test| or |mach mochitest|.
This way all TEST_STATUS and log lines will be visible when developers are writing a new test.
MozReview-Commit-ID: 2nuKs9DLnx0
--HG--
extra : rebase_source : 1fc594b465a2a94dfcd85d56d042969af47f6f65
Non-restartless extensions are no longer supported in the wild, and none of
the remaining automation extension rely on Workers in their components.
MozReview-Commit-ID: bh3nwwfM1g
--HG--
extra : rebase_source : db16e8bfdc8148310675b1c8641f4321b2a89702
extra : source : d6bda91c66d6625fb98c427ad62b337696df5acf
On desktop use sub script loader during bootstrap instead of the overlay.
On android use a component that listens for browser windows to be created
and then use a sub script loader.
MozReview-Commit-ID: Knj5OdVNEMA
--HG--
extra : rebase_source : d3374e6bc5feccf5ec22d8bc33f4b829a82a71b8
Non-restartless extensions are no longer supported in the wild, and none of
the remaining automation extension rely on Workers in their components.
MozReview-Commit-ID: bh3nwwfM1g
--HG--
extra : rebase_source : ad3d131d6db984f4171c5f79b86de094d2cca1bf
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
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
We'll stop dispatching keypress events on web contents for conforming to spec of
UI Events. Some existing tests assumes that keypress events are fired even
when non-printable keys are pressed.
This patch makes them check the pref,
"dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content"
and only listen to keydown event instead of keypress even if the pref is true
and expected key event is not a printable key press.
MozReview-Commit-ID: 6bKoK7dsB0l
--HG--
extra : rebase_source : b3705b0814d5690e00208d0d3315f09f886c6f26
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
The marionette.logging preference has been deprecated for some time.
We will want to use the official marionette.log.level preference instead.
Supported preferences are listed in
testing/marionette/prefs/marionette.js.
MozReview-Commit-ID: 4Z6OgqITe14
--HG--
extra : rebase_source : 62eabd701e79002b3828c3452e634966a2846643
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
The MACHTYPE bash variable is an odd thing that returns e.g.
x86_64-redhat-linux-gnu on a CentOS system, but x86_64-pc-linux-gnu
on a Debian system, and possibly something different on other distros.
mach valgrind-test is the only place actually relying on MACHTYPE.
Others rely on information from python modules. Uniformize that, and use
the more generic 'pc' rather than 'redhat'.
--HG--
rename : build/valgrind/i386-redhat-linux-gnu.sup => build/valgrind/i386-pc-linux-gnu.sup
rename : build/valgrind/x86_64-redhat-linux-gnu.sup => build/valgrind/x86_64-pc-linux-gnu.sup
extra : rebase_source : ad94ce69e8094d2b9ddae97a3d261945886c0a61
This is necessary before we enable the ESLint rule to require using
ChromeUtils for module imports rather than older methods.
MozReview-Commit-ID: mKqByUS0o2
--HG--
extra : rebase_source : d4b856aac7ff7eddc37cbf591c4e6522c45453e2
extra : histedit_source : 1ca2b6031e480fb44a15991241901224acc9e52f
Since gBrowser is going to become a plain JS object instead of a DOM node,
we don't want any callers directly referring to the DOM node to get ahold of it.
MozReview-Commit-ID: KbE5dlTWmS
--HG--
extra : rebase_source : ef4caea778db406205b58b9f007846dabb062978
This uses the 'mach' format by default when running mochitests
from a one-click-loaner. This is now consistent with the default
when running mochitests locally.
MozReview-Commit-ID: LYQbGm71Of8
--HG--
extra : rebase_source : a0a042ae1f7af8b09f80cf1b4dc33a58e67f333e
The suite name is no part of the suite_start message and can be printed via a
mozlog formatter. We shouldn't be printing this directly to stdout from |mach
mochitest|.
MozReview-Commit-ID: TOuqfEF14
--HG--
extra : rebase_source : 23bb214e6c1eedccf95abe08bb06b187728599d5
The suite name is no part of the suite_start message and can be printed via a
mozlog formatter. We shouldn't be printing this directly to stdout from |mach
mochitest|.
MozReview-Commit-ID: TOuqfEF14
--HG--
extra : rebase_source : ebcf6e37b77a0ca1e6da242df9066d4b41286d5c
SynthesizeDrop synthesizes a dnd operation by starting a drag session and firing mouse events. Tweak the API to follow the order of real use cases.
MozReview-Commit-ID: 1SdJPUtSVKq
The suite name is no part of the suite_start message and can be printed via a
mozlog formatter. We shouldn't be printing this directly to stdout from |mach
mochitest|.
MozReview-Commit-ID: TOuqfEF14
--HG--
extra : rebase_source : 15db5dc64476c52c91e59868c3653d5962870a5d
When 'summary_on_shutdown' is True (which is the case for |mach test| and |mach
mochitest|), BaseSummaryFormatters will save the summary information until the
'shutdown' action is received at the end of the logger's lifetime.
Summary information will no longer be dumped on 'suite_end'.
MozReview-Commit-ID: HKtVr5PxfOy
--HG--
extra : rebase_source : f350f09111deb510b27a4e55797243dda3160869
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
We should follow the real use cases to synthesize mouse or touch events to generate pointer events so that the related logic is covered by these test cases.
MozReview-Commit-ID: 9xSgjSL0Azt
In order for |mach test| and |mach mochitest| to log an overall summary,
every test harness invocation they make needs to use the same structured
logger (otherwise the affected suite will be missing from the summary).
MozReview-Commit-ID: 8LJw7r8SItk
--HG--
extra : rebase_source : 1417dce3817bae94ad61a5250065c6cbc35857e4