As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
As an intermediate step to allow mach commands as standalone functions, the MachCommandBase
subclass instance that currently corresponds to self has to be made available as a separate
argument (named command_context).
Differential Revision: https://phabricator.services.mozilla.com/D109650
In bug 1174288 and related bugs we created a framework for generating
test certificates (and later, keys) from specifications at build time. This
turned out to take too long to run on each build, so this system was largely
left disabled (see all of the "# Temporarily disabled. See bug 1256495."
comments removed in this patch). This patch introduces a mach command
("generate-test-certs") that can generate test certificates and keys. The
expectation is that when a developer needs to add new such artifacts, they can
use this new command. Similarly, when the artifacts need to be updated (for
example, because they've expired), this command can regenerate them all at
once.
Differential Revision: https://phabricator.services.mozilla.com/D108869
This file is also used by some browser-chrome tests which are still Python 2
for now. So let's not drop PY2 compat just yet.
Depends on D109728
Differential Revision: https://phabricator.services.mozilla.com/D111728
Looks like spoofing the event is not enough as GeckoView intialization code
(indirectly) uses the profile folder.
We also catch exceptions coming from the init code and throw them appropriately
so we don't ignore errors during initialization.
Differential Revision: https://phabricator.services.mozilla.com/D109797
This variable can be used by platforms to modify the current directory, useful
on Android as the process where the xpcshell test runs does not really have the
concept of CWD.
Differential Revision: https://phabricator.services.mozilla.com/D106207
This variable can be used by platforms to modify the current directory, useful
on Android as the process where the xpcshell test runs does not really have the
concept of CWD.
Differential Revision: https://phabricator.services.mozilla.com/D106207
We always used to pause when "attaching" the thread actor.
We ought to call ThreadActor's attach method first before using it.
And this method do various things:
* Initialize the Debugger API, enable it, register various listeners, so that breakpoint can work,
* Pause the current thread by starting a nested event loop
So that we also ought to resume the thread, by calling ThreadActor's resume right after attach.
Otherwise the page would be paused as soon as we open the DevTools.
Which sounds like something we might have wanted a very long time ago.
But sounds like pure legacy behavior from today's perspective.
Differential Revision: https://phabricator.services.mozilla.com/D99919
This patch enables PSM and Firefox to use TLS 1.3 Encrypted Client Hello (draft -08). Specifically:
- Compile NSS with NSS_ENABLE_DRAFT_HPKE=1
- Add ECH "public_name" handling in SSLServerCertVerification.cpp (see: https://tools.ietf.org/html/draft-ietf-tls-esni-08#section-6.3.2)
- Adds `mIsAcceptedEch` to TransportSecurityInfo, and xpcshell tests for ECH use cases
- Adds EncryptedClientHelloServer to facilitate the xpcshell tests
- Un-ifdef Set/GetEchConfigs code in nsNSSIOLayer.cpp. Also reverted the Base64 encoding and decoding, as the data returned from DNS is already decoded (wire-format).
Differential Revision: https://phabricator.services.mozilla.com/D92651
This patch enables PSM and Firefox to use TLS 1.3 Encrypted Client Hello (draft -08). Specifically:
- Compile NSS with NSS_ENABLE_DRAFT_HPKE=1
- Add ECH "public_name" handling in SSLServerCertVerification.cpp (see: https://tools.ietf.org/html/draft-ietf-tls-esni-08#section-6.3.2)
- Adds `mIsAcceptedEch` to TransportSecurityInfo, and xpcshell tests for ECH use cases
- Adds EncryptedClientHelloServer to facilitate the xpcshell tests
- Un-ifdef Set/GetEchConfigs code in nsNSSIOLayer.cpp. Also reverted the Base64 encoding and decoding, as the data returned from DNS is already decoded (wire-format).
Differential Revision: https://phabricator.services.mozilla.com/D92651
- Add 2 test: 1) server is not listening to the port and 2) server is not responding that will cause the connection to timeout and fall back to HTTP2
- Adds a server that only reads packets but never sends any to simulate a handshake timing out
Differential Revision: https://phabricator.services.mozilla.com/D95816
- Add 2 test: 1) server is not listening to the port and 2) server is not responding that will cause the connection to timeout and fall back to HTTP2
- Adds a server that only reads packets but never sends any to simulate a handshake timing out
Differential Revision: https://phabricator.services.mozilla.com/D95816
- Add 2 test: 1) server is not listening to the port and 2) server is not responding that will cause the connection to timeout and fall back to HTTP2
- Adds a server that only reads packets but never sends any to simulate a handshake timing out
Differential Revision: https://phabricator.services.mozilla.com/D95816
This will allow us to make response that violate the Http3 protocol and cause a protocol error.
Currently the server returns only one response, we may extend it if needed.
Differential Revision: https://phabricator.services.mozilla.com/D94912
This preference is currently only used when running Windows XPCShell
tests in order to disable IPv6 resolution for "localhost". However, this
does not seem to be needed anymore and actually breaks the expectation
that "localhost" resolves to IPv4 and IPv6 loopback addresses
(see bugs 1673315, 1673364, 1220810).
Differential Revision: https://phabricator.services.mozilla.com/D94986
Now that we're e10s by default, we need to disable it for xpcshell.
Unfortunately we can't do this via user prefs because, by the time xpcshell
parses those, it's already too late: e10s has already been decided.
In an earlier patch, we've changed that env var to accept '1' for Android,
instead of the version string as on desktop.
Differential Revision: https://phabricator.services.mozilla.com/D94337
Now that we're e10s by default, we need to disable it for xpcshell.
Unfortunately we can't do this via user prefs because, by the time xpcshell
parses those, it's already too late: e10s has already been decided.
In an earlier patch, we've changed that env var to accept '1' for Android,
instead of the version string as on desktop.
Differential Revision: https://phabricator.services.mozilla.com/D94337
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
If *all* test paths don't resolve to any tests and we're running in CI, exit without
causing the task to fail. This situation can happen due to moz.build traversal that
causes manifests to not exist under certain configurations.
Ideally I'd love if we could prevent those cases from happening in the first place (i.e
generate the 'all-tests.pkl' file via a file-system traversal and then rely on skip-if's
to not run things), but until then this fixes a fairly frequent intermittent.
Differential Revision: https://phabricator.services.mozilla.com/D93684
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
The manifest file hasn't actually done anything since XPT definitions were
moved to the libxul binary, and now just generates warnings in local builes.
Differential Revision: https://phabricator.services.mozilla.com/D89197
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
6.5 A ServiceMode RR is considered "compatible" with a client if the
client implements support for all its mandatory keys. If the SVCB
RRSet contains no compatible RRs, the client will generally act as if
the RRSet is empty.
Differential Revision: https://phabricator.services.mozilla.com/D85838
This allows to test them in the exact same environment as the tests are
going to run, which turns out to have revealed a few issues that would
only appear once xpcshell tests fail, impeding on debugging those
failures.
Differential Revision: https://phabricator.services.mozilla.com/D84781
This allows to test them in the exact same environment as the tests are
going to run, which turns out to have revealed a few issues that would
only appear once xpcshell tests fail, impeding on debugging those
failures.
Differential Revision: https://phabricator.services.mozilla.com/D84781
When using unittest rather than mozunit, something seems to be holding
onto the XPCShellTests, which keeps the subprocess objects around even
after we shut them down, and in turn, that keeps the pipe file
descriptors associated with the subprocesses around, effectively leaking
them for the duration of the entire selftest, which in some cases could
exhaust the system resources allocated to the selftest process.
Differential Revision: https://phabricator.services.mozilla.com/D84471
Also make sure we distribute the `http3server` binary in the common test archive, and download it for artifact builds.
Differential Revision: https://phabricator.services.mozilla.com/D84421
Remove some exclusions so that more files are linted. These exclusions had
been made to allow for code that was not py3 compatible, but with recent
py3 efforts, the exclusions can be removed. (Linting subsequently found
a few small issues which needed to be fixed.)
Differential Revision: https://phabricator.services.mozilla.com/D84393
Copy ensure_subprocess_env from mozbuild.util (not currently accessible from the
automation mozharness environment) to xpcshell harness, and use it.
Differential Revision: https://phabricator.services.mozilla.com/D84020
Resolve two py3 issues in remotexpcshelltests.py:
- use six.iteritems() to iterate on the env dict
- use 'wb' to create the log file
Some cleanup rides along (I couldn't resist).
Differential Revision: https://phabricator.services.mozilla.com/D79753
Support 'mach xpcshell-test' in a KaiOS environment. This is very much like running xpcshell in an android/geckoview environment except instead of using an APK for the gre, it uses the omnijar.
Differential Revision: https://phabricator.services.mozilla.com/D75545
Previously this would typically set GRE_HOME to /data/data/org.mozilla.geckoview.test,
even though org.mozilla.geckoview.test is not normally installed when running
xpcshell tests -- a non-existent directory in a privileged location!
The new location, remoteBinDir, is typically /data/local/xpcb, the location of the
xpcshell executable.
Differential Revision: https://phabricator.services.mozilla.com/D74938