Run with fission by default in test harnesses, with --disable-fission available as an
option.
Android mach commands automatically set --disable-fission; this can be over-ridden by
--setpref=fission.autostart=true.
fission.autostart is removed from all test profiles.
No changes to wpt, handled already in bug 1743714.
Differential Revision: https://phabricator.services.mozilla.com/D135137
Run with fission by default in test harnesses, with --disable-fission available as an
option.
Android mach commands automatically set --disable-fission; this can be over-ridden by
--setpref=fission.autostart=true.
fission.autostart is removed from all test profiles.
No changes to wpt, handled already in bug 1743714.
Differential Revision: https://phabricator.services.mozilla.com/D135137
This adds a feature to moz-http2's doh path that helps test connection
cycling. We log the remote ports of DoH requests and expose an API to
fetch the log. A specific name will trigger us to send a delayed response
to help simulate network volatility. The log is then checked for correctness
in the test script.
Differential Revision: https://phabricator.services.mozilla.com/D131467
This adds a feature to moz-http2's doh path that helps test connection
cycling. We log the remote ports of DoH requests and expose an API to
fetch the log. A specific name will trigger us to send a delayed response
to help simulate network volatility. The log is then checked for correctness
in the test script.
Differential Revision: https://phabricator.services.mozilla.com/D131467
This adds a feature to moz-http2's doh path that helps test connection
cycling. We log the remote ports of DoH requests and expose an API to
fetch the log. A specific name will trigger us to send a delayed response
to help simulate network volatility. The log is then checked for correctness
in the test script.
Differential Revision: https://phabricator.services.mozilla.com/D131467
This adds a feature to moz-http2's doh path that helps test connection
cycling. We log the remote ports of DoH requests and expose an API to
fetch the log. A specific name will trigger us to send a delayed response
to help simulate network volatility. The log is then checked for correctness
in the test script.
Differential Revision: https://phabricator.services.mozilla.com/D131467
This adds a feature to moz-http2's doh path that helps test connection
cycling. We log the remote ports of DoH requests and expose an API to
fetch the log. A specific name will trigger us to send a delayed response
to help simulate network volatility. The log is then checked for correctness
in the test script.
Differential Revision: https://phabricator.services.mozilla.com/D131467
The order in which we send A/AAAA requests is unspecified.
This test assumed the A request is always first. If we change that logic,
then the variable ends up != 0 on the second request, so we don't get the
proper response anymore.
This patch changes the server handler so it returns the proper response
after decoding the request packet.
Differential Revision: https://phabricator.services.mozilla.com/D130043
The order in which we send A/AAAA requests is unspecified.
This test assumed the A request is always first. If we change that logic,
then the variable ends up != 0 on the second request, so we don't get the
proper response anymore.
This patch changes the server handler so it returns the proper response
after decoding the request packet.
Differential Revision: https://phabricator.services.mozilla.com/D130043
A call to InitCommandLine was added in Bug 1727180 where gArgc and gArgv are
not defined.
The same bug also re-enabled some tests that appeared to pass (but really they
were just silently crashing), this patch fixes that too.
Differential Revision: https://phabricator.services.mozilla.com/D130223
The fact that the test runner app is defined inside the geckoview test package
has always felt like a hack to me. I've mistakenly thought that
TestRunnerActivity was used in GeckoView's junit tests many times (even though
that's not the case).
From what I can see, there's no way to generate an AAB package for androidTest,
so to be able to run Gecko tests as AAB we finally need to define the
TestRunner as an ordinary package instead.
Differential Revision: https://phabricator.services.mozilla.com/D127320
Sometimes we try to start a process that already exists and that causes a very
confusing error (the test times out but there's no indicastion as to why).
This patch makes it so that we will first try to kill the existing zombie
process and then, if we fail to do so, throw an error.
Differential Revision: https://phabricator.services.mozilla.com/D128937
xpcshell-test runs up to 10 concurrent tests and the logs are all interleaved.
This patch adds the test name to every log statement to let developers know
what test is causing the log line to appear in the logs.
Differential Revision: https://phabricator.services.mozilla.com/D128936
This ensures Glean is initialized in an xpcshell environment on Android.
When GeckoView is embedded the surrounding app is responsible to
initialize Glean from the Kotlin side.
This also enables the first few FOG tests to run on Android.
For now it changes the Android-specific test file.
As long as not all metric types are enabled we can't reliably test other metrics.
Differential Revision: https://phabricator.services.mozilla.com/D127420
In strict fallback mode, confirmation should still catch cases when the provider is
unavailable for whatever reason, and after that we should just fall back. This was
missing from bug 1714182.
Differential Revision: https://phabricator.services.mozilla.com/D126168
In strict fallback mode, confirmation should still catch cases when the provider is
unavailable for whatever reason, and after that we should just fall back. This was
missing from bug 1714182.
Differential Revision: https://phabricator.services.mozilla.com/D126168
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
This removes the `@CommandProvider` decorator and the need to implement
mach commands inside subclasses of `MachCommandBase`, and moves all
existing commands out from classes to module level functions.
Differential Revision: https://phabricator.services.mozilla.com/D121512
The goal here is to ensure we can always rely on `AppShutdown::GetShutdownPhase` to be in sync with the "real" application status, mainly this was needed for xpcshell tests to not break if we add assertions on our shutdown state on some global singletons.
We keep the existing observer notification topics but force them (on the parent process) to be issued through the new `advanceShutdownPhase` function of the startup service using the `ShutdownPhase` enum. This way we can synchronize `AppShutdown`'s internal status accordingly.
Some further notes:
# The `MOZ_ASSERT(AppShutdown::IsNoOrLegalShutdownTopic(aTopic));` in `NotifyObservers` helped a lot to identify missing cases. I think we should keep it in order to stay safe.
# Introducing the `cenum IDLShutdownPhase` helps to keep the knowledge about the mapping from shutdown phases to observer topics exclusively inside AppShutdown.cpp. Still callers must know what they do in order to choose a proper phase, of course.
# However we must be aware that `AppShutdown` this way can be kept in sync with the shutdown notifications only in the parent process and that `GetCurrentShutdownPhase` might not give the correct result in child processes. We might want to file a follow up bug that adds some asserts to avoid improper use of `AppShutdown` functions in child processes (but I do not want to make this patch bigger as needed to solve the blocking dependency for bug 1697972).
# The socket process is one example of a child process that "overloads" shutdown topics. I was wondering if it is the right call to use the very same topic names here to request shutdown to the socket process or if it should have its own topics. Those topics triggered the assert and thus I had to disable it for child processes, for now.
# This goes together with the more general approach to define process type specific shutdown phases (and hence mappings to topics) as drafted very roughly in bug 1697745.
# This patch seemed to trigger a known intermittent more often, thus the change here in `ServiceWorkerManager`.
Differential Revision: https://phabricator.services.mozilla.com/D124350
In GeckoView we check for this variable to determine whether we're running in
automation, but until now we never set it for xpcshell.
Differential Revision: https://phabricator.services.mozilla.com/D122380
The new tests in testing/xpcshell/example/ cover the following scenarios:
- Local AND remote xpcshell tests. In contrast, modifications to
selftest.py in bug 1635227 only covered runxpcshelltests.
- `prefs=` inheritance from ancestor manifests as implemented by
https://hg.mozilla.org/mozilla-central/rev/ac51a01611dc
- Per-file `prefs` setters (used in bug 1638099).
- Multiple prefs and comments per `prefs` line.
Differential Revision: https://phabricator.services.mozilla.com/D121632
Geoff Brown
Butkovits Atila
Joel Maher
Chris H-C
Nihanth Subramanya
Noemi Erli
criss
Alexandru Michis
Marian-Vasile Laza
Dragana Damjanovic
Julian Descottes
Valentin Gosu
Agi Sferro
Kershaw Chang
Jan-Erik Rediger
Mark Banner
Manuel Bucher
Alex Lopez
Jens Stutte
Aaron Klotz
Rob Wu