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
GCC 8 complains that `epochLimit` has no object linkage. Moving the constant
into the top-level fixes this issue. GCC 9 no longer needs this workaround.
Depends on D211395
Differential Revision: https://phabricator.services.mozilla.com/D211396
GCC 8 complains when calling `mozilla::CountLeadingZeroes64` in a `constexpr`, because
`mozilla::CountLeadingZeroes64` isn't `constexpr`.
Remove `constexpr` from all functions which are (transitively) calling
`mozilla::CountLeadingZeroes64`.
Differential Revision: https://phabricator.services.mozilla.com/D211393
Using `EnumSet` instead of `std::initializer_list` will make integration of
more built-in calendars easier. And `EnumSet` can also be passed more
efficiently (in a single register).
Also merges the two `Temporal.Calendar.prototype.mergeFields` implementations, so
we can more easily extend it when adding support for more built-in calendars.
Differential Revision: https://phabricator.services.mozilla.com/D211187
