The cleanup work done from didDestroy was only calling `unwatch` on the Watcher classes,
which was typically unregistering the platform listeners.
We were missing calling `destroyTargetsForWatcher` on them which is meant to destroy
the target actors, which can also register platform listeners and be leaking data.
Differential Revision: https://phabricator.services.mozilla.com/D210366
Stop unregistering the JS Process actor when removing the last watched target/resource type.
Instead only unregister it when the Watcher Actor is destroyed.
It prevents some race condition where unwatch request (which aren't awaited for)
unregister the actor late and the next test/next toolbox opening would have its actor
unregistered by late destruction code related to the previously closed toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D210365
This is important to spawn this ESM only once between regular and browser toolbox,
and especially between various callsites used by the browser toolbox.
Otherwise we may start loading modules in two distinct system loaders
and may have inconsistancies when using `instanceof`.
Differential Revision: https://phabricator.services.mozilla.com/D207432
Modifying the content of the list of resources may suddently start or stop receiving new resources types,
that, without calling (un)watchResources again!
Differential Revision: https://phabricator.services.mozilla.com/D205603
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
The UI test takes use of the retry rule and was flaky because:
# on the first try after performing the click on the "Switch" button nothing happened (should switch to private browsing)
# on the second and third retry, the switch to private browsing is properly performed, but when trying to verify the existing open tabs, an empty tabs tray was displayed
The problem on the second and third retry most likely happened because of some syncing problems between UIAutomator and Compose.
Noticed in the past that in some cases the wait performed using UIAutomator will block the the test if the next steps are being performed with Compose.
To overcome this problem, I've replaced the UIAutomator **waitForExists** with **waitUntilAtLeastOneExists** that is part of Compose in the **verifyExistingOpenTabs** function.
The UI test successfully passed 300x on Firebase ✅
Ran all UI tests 1x on Firebase and successfully passed ✅
Differential Revision: https://phabricator.services.mozilla.com/D211367
System fonts can leak any user customization of system fonts, or user's
locale (e.g., en-US and ja Windows have different system fonts).
Also, Linux distributions/desktop environments set default fonts in
different ways.
Customization can be detected either with font metrics, the font allowed
list is not enabled or the font is included in it, or with
getComputedStyle, that leaks the name of the font that Firefox tries to
apply.
This patch try to prevent these leaks by using a generic "sans-serif"
for all system fonts, except on macOS, where it uses "-apple-system",
and on Android, where these fonts always use Roboto.
Differential Revision: https://phabricator.services.mozilla.com/D163576
Now that the a11y engine correctly traverses aria-labelledby during name computation per the spec, the aria-labelledby overrides the content of the cell when computing the name for the tree item.
Strictly speaking, putting aria-labelledby on a span is a spec violation these days anyway.
Differential Revision: https://phabricator.services.mozilla.com/D211503
Continuations occur when text wraps onto a new line (fluid continuations), but they also occur when the text direction changes (non-fluid continuations).
Previously, TextLeafRange assumed that all continuations were line breaks.
Now, we explicitly treat fluid continuations as line breaks.
It's also possible for a non-fluid continuation to be on a different line if the text direction changes between the end of the previous line and the start of another.
In that case, we must use a line iterator to check whether they are on different lines.
Differential Revision: https://phabricator.services.mozilla.com/D210893
GC hazard analysis complains that `const TemporalFields FallbackValues{}` contains
GC things and the `GetProperty` call in the next (!) loop iteration may trigger a GC.
Workaround this warning by moving `const TemporalFields FallbackValues{}` into a
separate function.
Depends on D211399
Differential Revision: https://phabricator.services.mozilla.com/D211400
Running the tests with optimisations enabled uncovered a bug in the
shift operator implementations:
The code from "Hacker's Delight" assumes that shifting an N-bit integer by N bits
returns zero, i.e. `i64 >> 64 == 0`, but this is undefined behaviour in C++. The
shift operators executed this case when `shift == 0`, because then
`low >> (64 - shift) == low >> (64 - 0) == low >> 64`. Add an extra branch to
handle the case when `shift` is zero to avoid hitting UB.
Depends on D211398
Differential Revision: https://phabricator.services.mozilla.com/D211399
Only recent Clang/GCC implement CWG2518. Workaround this limitation by directly
calling `std::abort`.
GCC <10 complains about unused functions in `constexpr` contexts. This can be
worked around by adding a couple of `[[maybe_unused]]`.
The `to_array` function to implement `std::to_array` from C++20 doesn't compile
under older GCC, because the compiler doesn't add necessary type conversions.
Explicitly casting all inputs to `int64_t` resp. `uint64_t` fixes this. With
the explicit casts it's no longer necessary to call `to_array' and we can
instead directly create the `std::array`.
Depends on D211397
Differential Revision: https://phabricator.services.mozilla.com/D211398
GCC 8 doesn't like `MOZ_CRASH` in a `constexpr` function. The `constexpr` functions
are used for `static_assert`s, so removing `constexpr` isn't possible without also
losing the `static_assert`. `MOZ_CRASH` is allowed starting with GCC 9, so for now
simply call `std::abort` when under GCC 8 and hope nobody is too mad about missing
crash annotations when compiling with GCC 8.
Depends on D211396
Differential Revision: https://phabricator.services.mozilla.com/D211397
