Start Firefox with -foreground and -no-remote arguments if they
have not already been given by the user.
-foreground will ensure the application window gets focus when
Firefox is started, and -no-remote will prevent remote commands to
this instance of Firefox and also ensure we always start a new instance.
MozReview-Commit-ID: LGEqgyHYapc
--HG--
extra : rebase_source : 50054e89106421dc6b43bc1f109dc75db37dfd2d
The std::process::Command's stdout and stderr is configured earlier in
::start(), and resetting it to a static value below would invalidate the
configured stdout and stderr stored in FirefoxRunner::stdout and ::stderr.
We did not notice this bug because geckodriver does not
yet use this feature. It was added as a precursor for
https://bugzilla.mozilla.org/show_bug.cgi?id=1466573.
MozReview-Commit-ID: CmwqCZpEMqq
--HG--
extra : rebase_source : 209d7cdde8b05db9b7e6f02b221c32a436f2ecdf
Bug 1464995 broke mozrunner on macOS, but we did not notice because
geckodriver is not compiled on macOS. This fixes the build.
MozReview-Commit-ID: GnvZTT30wHG
--HG--
extra : rebase_source : 6e5b5b37d0c962c75a2a4b41c004f9cf47c2e8a2
mach android-emulator currently supports 6 different avds; I am struggling to maintain
that many configurations. I don't see a lot of value in keeping both 6.0 and 7.0,
and Android 6.0 is not as popular as 7.0. Let's remove 6.0, encouraging 7.0 as an
alternative; same for x86-6.0 -> x86-7.0.
mozrunner fails to locate the correct binary if Firefox is found
under a "firefox" or "firefox-bin" (depending on the system)
because it thinks the parent directory is the executable.
On Unix systems, mozrunner also falsely reports non-executable
files as valid binaries.
This patch introduces a new mozrunner::path module that provides
two functions: one for searching the system path for a binary by a
given name, and another for checking whether a path is an executable
binary file.
MozReview-Commit-ID: 6N06CXZZWqd
--HG--
extra : rebase_source : dbcb4d6d8478bafc23c1aa2a3081589074908bbc
Removes an unnecessary as_ref() cast, a path coercion, and replaces
try!() with ?.
MozReview-Commit-ID: ASd9kNxDZ3n
--HG--
extra : rebase_source : fa88def64fc3c7ea4520403bfc7b5c391d7f83da
The method we use to find the Firefox binary varies from platform
to platform. It can be useful to document how each of the system
specific implementations are meant to work.
MozReview-Commit-ID: 4SrNmlp3AdS
--HG--
extra : rebase_source : f1d54548edb416912af3a0a6d41188d0640a3ffb
Parent tests may also have stacktraces and this patch prints and
formats them the same way we do for subtests' stacks.
MozReview-Commit-ID: 64gfPWuQnHd
--HG--
extra : rebase_source : 6a37eda231091d66a92226c3ebadb7b7980766be
Instead of downloading the build artifacts (rather hackily) in moztest.fixtures, this now happens
directly in the taskgraph module via the run-task script.
For now extraction and setup happens in the task's command key. It might be a good idea to figure
out a syntax to tell run-task to do this extraction, e.g something like:
run:
using-artifacts:
build:
target.tar.bz2:
extract: true
path: /home/worker/build
name: firefox
But for now I wanted to avoid this extra complexity, so maybe it could be done in a follow-up.
MozReview-Commit-ID: KOhFFpFdP7Y
--HG--
extra : rebase_source : dcea36661fa9c6442c76c850ccc67f8f6d924fda
Before this patch, the x86-6.0 and x86-7.0 Android emulators were
unusable on macOS (tested 10.13.4 High Sierra).
The emulator's UI appears (but with black screen), and the launcher
icon in the dock has a default folder icon instead of the emulator.
When I use "mach android-emulator --version=x86-6.0 --verbose",
then the full emulator command is printed. I discovered that
using the newer QEMU 2 engine ("-engine qemu2") fixes the issue, and
that the emulator launches as expected. This option is documented at:
https://developer.android.com/studio/run/emulator-commandline
However, when I modify the source of these commands, then the emulator
fails to start (as before). This is caused by the setpgid call via
preexec_fn in testing/mozbase/mozprocess/mozprocess/processhandler.py .
Passing ignore_children=True to ProcessHandler avoids the setpgid call
and allows the emulator to be used as expected on macOS.
The effect of not using setpgid is that the spawned process will not
be put in the process group of the "mach" Python script. This is not
a big deal. I can confirm that the emulator can still be killed by
quitting or force-quitting it, and did not experience other issues.
MozReview-Commit-ID: 4AKVqtwIoCj
--HG--
extra : rebase_source : df6615a32de666d0f9d4f27c1c6f462120364ee2
Following the move to use cargo worktrees in central, the .gitignore
file for mozversion is not used anymore since we no longer generate
testing/mozbase/rust/mozversion/target on building.
MozReview-Commit-ID: 72geBjNxjZl
--HG--
extra : rebase_source : d7f11b33c91407e97416344ca1a2d0f06aa573d3
In bug 1440714, mozdevice had its version bumped to 1.0.0, outside of the required
range in mozrunner's deps, causing in-tree breakage. Subsequently, I changed mozrunner's
dep list to allow for mozdevice 1.0.0, and released mozdevice 1.0.0 on pypi. Now I need
to update mozrunner on pypi with the updated deps, so require a mozrunner version bump.
This is mainly to pick up bug 1448221 since the version of mozprofile on pypi can't
install addons with nightly anymore (due to the profile/extensions/staged directory
not being supported).
But since that change I've also landed several backwards incompatible API changes to
how addons are installed.
Bumping to 1.0.0 because I'd like us to start (attempting) to follow SemVer:
https://semver.org/
MozReview-Commit-ID: FDIPqNnSKJ6
--HG--
extra : rebase_source : 4e083b77802c97b85436410b40225ad234b9e7fb
Neither package has any backwards incompatible changes. However, I decided to
bump the major version for mozrunner as this is the first time it's switching
to SemVer (mozprofile already made the switch). It seemed cleaner to have the
switch happen after a major bump.
In both cases, I've added major version upper limit guards to each dependency.
This way we won't break these packages in the future when we land backwards
incompatible changes to the dependendencies.
MozReview-Commit-ID: 5SIpMGTS3cc
--HG--
extra : rebase_source : 43ab4c9f3af50eb82a22ec3112e5b56fe703dbc6
In Chrome it doesn't seem to be possible to install extensions by dropping them
in the profile directory. Instead we use the --load-extension command line
argument. To that end the ChromeProfile uses a 'dummy' AddonManager() class
that is actually just a list with an 'install' method. Mozrunner will be
responsible for building the command line based on this list.
We also need a few other command line arguments to build and create a temporary
profile directory.
MozReview-Commit-ID: HC2p2ZZMl66
--HG--
extra : rebase_source : 2d748893e8530a312afb5d8b1442a4c29f93caf1
In addition to Profile, this will be implemented by the ChromeProfile class in
the next commit. This way we can test for 'isinstance(profile, BaseProfile)'
when we just want to test for a profile regardless of application.
Ideally I would have preferred 'Profile' itself to be the base class (and co-opt
FirefoxProfile to be the new defacto class for firefox profiles), but this would
break backwards compatibility.
MozReview-Commit-ID: 6TTFq2PQOGM
--HG--
extra : rebase_source : 57651887061ec52b176729109271ee2e23552cdb
This will make it a bit easier for consumers to create a profile instance. They
can just call:
profile = create_profile('firefox', prefs=...)
Instead of needing to first find the class, then do the instantiation.
MozReview-Commit-ID: 7FqAGsSyZVe
--HG--
extra : rebase_source : 3172189618d6948959edfc61d6782373d27a2cbb
This is a much cleaner and easier to understand test format. It will also make
it easier to add tests for the upcoming ChromeProfile changes.
MozReview-Commit-ID: DizKGt0qkPF
--HG--
rename : testing/mozbase/mozprofile/tests/addonid.py => testing/mozbase/mozprofile/tests/test_addonid.py
rename : testing/mozbase/mozprofile/tests/bug758250.py => testing/mozbase/mozprofile/tests/test_bug758250.py
rename : testing/mozbase/mozprofile/tests/permissions.py => testing/mozbase/mozprofile/tests/test_permissions.py
rename : testing/mozbase/mozprofile/tests/server_locations.py => testing/mozbase/mozprofile/tests/test_server_locations.py
extra : rebase_source : 07953fd02a8592ed31e1972d646ff93bfd25d80b
This allows consumers to bootstrap Chrome with mozrunner. For now the profile implementation
is just an empty class but this will be expanded in a future commit.
MozReview-Commit-ID: 1Z14FudH0JJ
--HG--
extra : rebase_source : b593965a6bd725b133adf42ff31d61726bcff520
This will make it easier to add the ChromeRunner tests in the next couple of
commits.
MozReview-Commit-ID: 2Nfz92FStSX
--HG--
rename : testing/mozbase/mozrunner/tests/mozrunnertest.py => testing/mozbase/mozrunner/tests/conftest.py
extra : rebase_source : 27837679b744e7f765fdb2d4f43d4bab14fb2dc0
This is a leftover artifact from the B2G days that isn't being used anymore.
MozReview-Commit-ID: FZoTwHltmAG
--HG--
extra : rebase_source : 455450f360fa222522f365118d1e687528e08b69
This isn't strictly related to this bug, but it is a change made to mozbase in
the raptor repo that is worth backporting here. Figured it's easiest to land it
alongside the other mozbase backports.
MozReview-Commit-ID: DW7I2zKZZNk
--HG--
extra : rebase_source : a000d27774f224d37f981d6683d96c65846b8a32
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.
I missed a couple of references in cleanup code. This wouldn't have caused any
failures but might result in addons not being cleaned up properly.
MozReview-Commit-ID: BX0oX2GRGWT
--HG--
extra : rebase_source : 2193adb4e96b8e70faa6ffb1afd6db698b10ad2d
The patch correctly marks the delimiters for the tree output
as Unicode, and also updates mozprofile to correctly serialize
the Profile object when str() is used.
MozReview-Commit-ID: AjUHa6zGHQe
--HG--
extra : rebase_source : d4fa6c5db91184dee6a2abe788aa23d0c6255be6
While we are removing a bunch of stuff and breaking backwards compatibility, I
figured this would be a good time to also change some of the APIs. These APIs
aren't used much in mozilla-central (and this patch updates the few places that
do).
This rolls the 'install_addons()' and 'install_addon_from_path' method into a
single 'install' method. This install method can accept a string or list of
paths to an individual addon (directory or .xpi), or a directory containing
addons.
This also renames Profile.addon_manager to Profile.addons, which reads better.
MozReview-Commit-ID: 7vDPnG4cKqu
--HG--
extra : rebase_source : 62f8613b9824e06e698d5af8dcbb4bcb07b8079e
This is another seemingly unused feature in mozilla-central.
Being able to download addons in AddonManager is a violation of the single
responsibility principle. If consumers *really* need to download addons, they
can easily do so with requests and then pass the file path in to AddonManager
like normal. There's no need to have this baked into AddonManager itself.
MozReview-Commit-ID: IorG0foiHfT
--HG--
extra : rebase_source : 27b4162d9adfb986c2b9822c12b6abc5a2561a9a
This feature isn't used anywhere in mozilla-central that I can tell. Because
using a manifest is the only way to install an addon from AMO, that ability has
also been removed with this commit.
MozReview-Commit-ID: BNFGPWdo96t
--HG--
extra : rebase_source : 9bc7c9c7e91b01b71082f763fb6e621c430de808
The build job on Windows sets the MINIDUMP_SAVE_PATH env variable,
and because it isn't unset mozcrash copies all created minidump
files from unittests to the "public/build" folder, which then
get uploaded as artifacts.
MozReview-Commit-ID: 6JNnRZGlOj3
--HG--
extra : rebase_source : c148e5a8ac4439ca0f4e66ee649b45ceb7b1bc60
If a ProcessHandler instance has been created, but mozprocess fails
to start the child process, a dangling process_handler instance is
attached to the runner instance. This should be avoided, and a
RunnerNotStartedError has to be thrown.
MozReview-Commit-ID: LgNFVaT9qVs
--HG--
extra : rebase_source : c06aef08d7619ac9d3fe94ad29bdae06f0f79364
Without encoding the key and value of environment variables as UTF-8
for non-interactive sessions "subprocess.Popen()" and specifically
"os.execvpe()" will fail.
MozReview-Commit-ID: 9lO562XnDZx
--HG--
extra : rebase_source : bba542648b6050d0e9f628c95b658c3a546d2b5d
The build job on Windows sets the MINIDUMP_SAVE_PATH env variable,
and because it isn't unset mozcrash copies all created minidump
files from unittests to the "public/build" folder, which then
get uploaded as artifacts.
MozReview-Commit-ID: 6JNnRZGlOj3
--HG--
extra : rebase_source : a139221b810e1b38082d5676b67583269802b7e9
One change since 0.6.0, which is a regression fix for a fallout
from bug 1443853.
MozReview-Commit-ID: 56GbEV4HM4v
--HG--
extra : rebase_source : 0e14fa63f00f1661cae01a10c76c2813d349ba1b
std::process::Child::kill() will return Err if the process has
already exited. The assumption in bug 1443853 was that calling
::kill() would consistently return the std::process::ExitStatus
was the process already dead.
This patches the regression from bug 1443853 by employing
Child::try_wait() in a loop. When the process gives some exit status,
this is return directly without relying on Child::kill() as before.
If the process has not exited and the timeout has elapsed, we kill
the process and return its return value. If the process has not
exited but the timeout duration has not elapsed, we wait 100 ms as before.
MozReview-Commit-ID: 4VENbrKtcEh
--HG--
extra : rebase_source : 7f27ed057da740306367ef2b6a87f8ac6a242541
This consolidates the printing of status logs, which was previously handled
differently in 3-4 places. This also fixes a few of the annoyances listed in
the bug 1445624 description. Finally this also fixes a few edge cases that I
noticed when writing the tests.
MozReview-Commit-ID: APudT8yBqVS
--HG--
extra : rebase_source : 943a71c762dd27a7f7ebea86d467e81a0b27d400
extra : source : 61ba86fc1366a62a429a7daab7d6b1c198c69593
This adds a basic test for the mach formatter. This will ensure that changes to
this format are intentional. It will also make it easier for reviewers of these
changes to see a diff of the old vs new format.
MozReview-Commit-ID: LBSfdyvOPVV
--HG--
extra : rebase_source : 5529ad1f03306dcf867d88af579b69d6005091c0
To let mozcrash handle minidump files located in profile paths
with unicode characters, support for that has to be added. It
also applies to the locations for the stackwalk binary, minidump
save path, and symbols.
MozReview-Commit-ID: EROVmK21a5Y
--HG--
extra : rebase_source : 67092e6164eb0e46decd24b2da1490ffefb4d5d7
Switch to the pytest framework to benefit from its rich
feature set for creating Python test.
MozReview-Commit-ID: AoptjhT1Hln
--HG--
extra : rebase_source : a0870e54038697f08cf14e7babffdb014a7a3c7d
Right now if no minidump file is present in the minidump folder,
the check_for_crashes method returns False. Whereby in all other
cases the number of crashes is returned.
To be consistent this method should always return a number, and
in case of no minidumps it should be 0.
MozReview-Commit-ID: 3DTgxn41TVn
--HG--
extra : rebase_source : 1631313878b596607ede27ebb04f95a64e2f9e2e
Split single unit test module into different modules separated
by area of test coverage.
MozReview-Commit-ID: Blh8V46kDq1
--HG--
extra : rebase_source : 64bfa620286904fdb2bde114efb337d0dd5d42b7
There were two issues:
1) The mach command name in resolve.py was wrong.
2) The marionette harness uses deepcopy on the passed in kwargs and sometimes
the 'log' argument that testing/mach_commands.py was passing in can be a class
instance (which can't be deepcopied).
MozReview-Commit-ID: 5gPxuiHs3dY
--HG--
extra : rebase_source : 63bc9c84fdcb540862f1dcbc2654bf5729e0dec8
Remove RemoteB2GVersion from mozversion and associated parameters from
mozversion.get_version(). Other than the cli interface modified here,
there are no in-tree clients of get_version() using the remote parameters.
This moves the shutdown monitor for the Firefox process from
geckodriver to mozrunner, which is a more suitable home for it.
We will likely need specialised versions of this in the future with
products such as GeckoView and Fennec.
In addition to the move it also cleans up the polling loop by
employing std::time::SystemTime which lets us match on the elapsed
time since its construction. This seems nicer than having to perform
division operations on integers, which in Rust are inherently unsafe
(there is no guard against SIGFPE).
This change should be functionally equivalent to the existing code.
MozReview-Commit-ID: 1asnFbixhcY
--HG--
extra : rebase_source : f21f734862bfbbc1ed665dc9c9f611c5968d662f
Dave Hunt
Geoff Brown
Andreas Tolfsen
Rob Wood
Andreea Pavel
Joel Maher
James Graham
Andrew Halberstadt
Rob Wu
Gregory Szorc
Bogdan Tara
Henrik Skupin
Andrew Swan
Brindusan Cristian
Bob Clary
Coroiu Cristina
Tiberius Oros
Kris Maglione
arthur.iakab
Noemi Erli
Sylvestre Ledru