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
This patch would further improve the readability for wakelock test by doing following things.
1. refactor `getWakeLockState()` and rename it to `waitForExpectedWakeLockState()`
In the origin test, we have to create a wakelock sentinel object beforehand, and then call `check()` later, which is not really intuitive. Refactor that function to allow us to use it easier.
2. use const variables to store the wakelock topic (audio-playing/video-playing)
3. add a helper function `ensureNeverAcquireVideoWakelock()` to clearly indicate we won't acquire video wakelock for web audio
Differential Revision: https://phabricator.services.mozilla.com/D94778
Separate the media playback and web audio tests for wakelock, which can prevent running a time too long and hitting the error (bug 1522361) and increase test readability because some check conditions would only work for one side, which would be nonecessary for another side.
Differential Revision: https://phabricator.services.mozilla.com/D94777
As we changed the way we handle audible state in D94181, those tests also need to be modified in order to run without errors under new mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D94184
Currently we didn't consider the engine's output volume when we determine the audible state for the destination node, doing that would help us to more correctly deide the actual audible state for users.
Differential Revision: https://phabricator.services.mozilla.com/D94182
The main purposes of this patch is to
- changes the way the destination node holding the audio channel agent (holding the agent all the time)
That would help us
- earlier mute the destination node in order to prevent sound leaking
- request wakelock based on the actual audible state (considering more factors)
- improve the readability of handling audible state (the old way contains some weird workaround, eg. setting the node as audible in the beginning)
Differential Revision: https://phabricator.services.mozilla.com/D94181
- Make WaylandAllocateShmMemory() fallible.
- Implement WaylandReAllocateShmMemory() to re-allocate Shm pool.
- Remove WaylandShmPool::Resize() and use WaylandShmPool::Create() only.
- Implement and use WaylandShmPool::Release().
- Make WindowSurfaceWayland::CreateWaylandBuffer() as fallible.
Differential Revision: https://phabricator.services.mozilla.com/D94735
The latest launcher process showed one of the top failures was `WriteProcessMemory` in
`CopyStubToChildProcess` failed with `ERROR_INVALID_ADDRESS` or `ERROR_NOACCESS`, that
is to store a trampoline address to the global variable of firefox.exe failed. Its root
cause should be the same as bug 1662560, the executable was loaded onto a different
address from the browser process.
The fix is to to expand the usage of `CrossExecTransferManager` to `FuncHookCrossProcess`
and `Kernel32ExportsSolver`.
Depends on D94652
Differential Revision: https://phabricator.services.mozilla.com/D94653
This patch introduces a class `CrossExecTransferManager` to manage the data
transfer from the current process to a remote process via `WriteProcessMemory`.
The class also encapsulates a logic to bridge the gap between two executable's
imagebase.
Differential Revision: https://phabricator.services.mozilla.com/D94652
This re-works our tests to run all of the branches in the interposer. There is
a bit of a risk that this won't pass on all platforms as there is an allow list
of known operations. However, it's currently only limited to macOS and Linux.
Please note the placement of utility functions in shared-head.js if they were
generally useful beyond the xpcshell tests, and in xpcshell/head.js if the
functions were only useful for the specific FileIO tests.
Differential Revision: https://phabricator.services.mozilla.com/D93850
This commit uses the new Markers 2.0 API for FileIO Markers. I had to
create another option for the MarkerStack class in order to conditionally
capture a backtrace inside of the Macro. Otherwise the macro invocation
failed.
Differential Revision: https://phabricator.services.mozilla.com/D93848
This allows additional suffixes (e.g. -qr) to be added to ccov test platforms,
and in most cases those labels will be treated the same as the other ccov jobs.
In a few cases exact (non-regex) keys were left unmodified, because changing
a non-regex key to a regex key can result in taskgraph generation failure, if
more than one regex key matches.
I verified that this patch does not modify the output generated by `./mach
taskgraph full --json`.
Differential Revision: https://phabricator.services.mozilla.com/D94725
As with the previous patch, the negative regex makes changes hard. This replaces
the negative regex with a positive list of matching labels, similar to the one
a few lines down. I verified that this patch does not modify the output for
`./mach taskgraph full --json`.
Differential Revision: https://phabricator.services.mozilla.com/D94724
I need to modify the ccov regexes to allow additional suffixes. The negative-
search regex makes this hard, and seems quite complex/error-prone. Instead of the
negative-search regex, we can accomplish the same thing by splitting out a
new test-set.
Note that with this patch, there are a handful of jobs that get removed from
the list generated by `./mach taskgraph full` (listed below). I believe this
is a desirable change since per the comment in the code it seems like we don't
want these jobs to run. In fact, I don't see these jobs on TreeHerder, so maybe
some other step is pruning them out anyway.
The jobs being removed are below. The '*' at the end represents the chunk number,
each of the labels with a '*' has 6 chunks which I've collapsed into a single
label for brevity.
test-linux1804-64-asan/opt-jittest-1proc-*
test-linux1804-64/debug-jittest-1proc-*
test-linux1804-64-devedition/opt-jittest-1proc-*
test-linux1804-64/opt-jittest-1proc-*
test-linux1804-64-qr/debug-jittest-1proc-*
test-linux1804-64-qr/opt-jittest-1proc-*
test-linux1804-64-shippable/opt-jittest-1proc-*
test-linux1804-64-shippable-qr/opt-jittest-1proc-*
test-windows10-64-asan/opt-jittest-1proc
test-windows10-64/debug-jittest-1proc
test-windows10-64-devedition/opt-jittest-1proc
test-windows10-64/opt-jittest-1proc
test-windows10-64-shippable/opt-jittest-1proc
test-windows7-32/debug-jittest-1proc
test-windows7-32/opt-jittest-1proc
test-windows7-32-shippable/opt-jittest-1proc
Differential Revision: https://phabricator.services.mozilla.com/D94723
The test was using network.dns.localDomains to check that we don't
call into the platform DNS resolver when the network.dns.disabled pref
was set - but since the localDomains pref rewrites hostnames to localhost
and we now don't call into GetAddrInfo for local domains, the test
failed.
I changed it so it uses the NativeDNSResolverOverride to register an IP for
foo.bar instead of relying on localDOmains.
Depends on D94726
Differential Revision: https://phabricator.services.mozilla.com/D94727
Non wayland unified builds end up with a different set of files
combined which ends up causing the conflict. Remove the 'using namespace
mozilla::gfx' to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D94825
Depends on D94711
We might fold this in the first changeset after review.
Updated the links color of the whole panel to use a theme variable.
Used another theme variable for the button hover/active background color.
Differential Revision: https://phabricator.services.mozilla.com/D94747
Instead of loading instruction-internal simd constants separately (on
x86/x64) and thus potentially increasing register pressure by
requiring temps, load them as part of the operation.
This patch handles a few remaining single-use-of-loaded-const cases,
none of which are probably all that important, this is just hygiene.
In the case where a loaded const is used multiple times, or a single
use can't be gotten rid of without introducing additional moves, we
assume (for now) that it's OK to load the constant separately. The
cases that remain in this class are blends (that will use a mask and
its negation) and a few floating-point slow paths (some with multiple
uses, some with knotty logic).
Differential Revision: https://phabricator.services.mozilla.com/D94557
Instead of loading instruction-internal simd constants separately (on
x86/x64) and thus increasing register pressure by requiring temps,
load them as part of the operation.
This patch adapts the shuffle operation (pshufb). There's a fair
amount of plumbing in the assemblers but the change amounts to
inlining the constant loads into the instruction, getting rid of a
temp, and making sure we bias in favor of lhs == output.
Differential Revision: https://phabricator.services.mozilla.com/D94556