Talkback users expect that when you navigate past the end of the text in a node, Talkback will move into the next node and navigate there.
However, even though text navigation is async (client performs an action on the focused accessible and then waits for a text traversal event), firing a traversal event with a different accessible from the focused accessible is not supported by Talkback.
Firing a11y focus on the new node (as we did previously) doesn't fix this, but instead causes the entire node to be reported, among other weird behaviour.
1. Don't fire a11y focus for text traversal.
Aside from Talkback reporting the entire node, this was also confusing Talkback, causing it to try to navigate several times into the new node.
2. When navigating text, cache whether we're at either edge.
We do this because we need to be able to synchronously query whether we're at the edge, but we do navigation async.
Special handling is needed for words at the end because words don't include trailing space.
3. When performing a text navigation action, check if we're already at the edge using the cache described above.
If we are, synchronously return false, as Talkback expects.
Talkback will then move to the next/previous node itself and navigate the text there.
Differential Revision: https://phabricator.services.mozilla.com/D57926
--HG--
extra : moz-landing-system : lando
This is the last part needed to be able to restrict results without an explicit
typed token (either restriction or alias). Note this is all preparatory work,
there isn't a design for a feature using this yet, but we know at a certain
point we want a more usable representation of aliases and restriction tokens
and eventually a mode picker UI (search button).
Differential Revision: https://phabricator.services.mozilla.com/D57781
--HG--
extra : moz-landing-system : lando
These currently are Mozilla-only but can be trivially moved into upstream
tests once there is agreement to take the feature.
Depends on D57472
Differential Revision: https://phabricator.services.mozilla.com/D57473
--HG--
extra : moz-landing-system : lando
This is exactly the kind of test that makes no sense once we have finished
the rework of RDM (to be embedded into the browser UI). Indeed, once done,
there won't be a nested iframe in RDM through which we need to make sure
all messages that lead to the tab status/title/icon (and many other things)
are forwarded.
So, because this test currently fails with fission, let's just disable it
for now when in fission mode, and then once the RDM project is done, let's
delete it entirely. No use spending time making it work now if we're going
to remove it later.
Differential Revision: https://phabricator.services.mozilla.com/D57758
--HG--
extra : moz-landing-system : lando
ProcessRedirect.cpp includes third-party udis86 C code that triggers -Wimplicit-fallthrough warnings. We suppress these warnings in ProcessRedirect.cpp because we want to minimize Mozilla changes to third-party code and we can't use C++17's [[fallthrough]] attribute in C code anyway. We don't suppress the warnings for the entire ProcessRedirect.cpp file (e.g. in moz.build) because we'd like clang -Wimplicit-fallthrough to check ProcessRedirect.cpp's own use of [[fallthrough]].
This changeset reverts some earlier Mozilla changes [1] made to upstream udis86's decode.c [2] that are no longer necessary.
[1] https://hg.mozilla.org/mozilla-central/rev/9042673fb235c00fbb021ea6356f4b0921505d1d
[2] https://github.com/vmt/udis86/blob/master/libudis86/decode.c#L747
Differential Revision: https://phabricator.services.mozilla.com/D56441
--HG--
extra : moz-landing-system : lando
This changeset is a simple find and replace of `MOZ_FALLTHROUGH` and `[[fallthrough]]`.
Unfortunately, the MOZ_FALLTHROUGH_ASSERT macro (to assert on case fallthrough in debug builds) is still necessary after switching from [[clang::fallthrough]] to [[fallthrough]] because:
* MOZ_ASSERT(false) followed by [[fallthrough]] triggers a -Wunreachable-code warning in DEBUG builds
* but MOZ_ASSERT(false) without [[fallthrough]] triggers a -Wimplicit-fallthrough warning in NDEBUG builds.
Differential Revision: https://phabricator.services.mozilla.com/D56440
--HG--
extra : moz-landing-system : lando
Ion is only interested in the global lexical environment, a singleton. Don't
waste time tracking property types for other environments.
Depends on D57776
Differential Revision: https://phabricator.services.mozilla.com/D57777
--HG--
extra : moz-landing-system : lando
The two masks are used only in nsBlockFrame::Init, so they should be
defined closer to their usage.
Note that 'constexpr' declared on functions implies 'inline'.
Differential Revision: https://phabricator.services.mozilla.com/D57724
--HG--
extra : moz-landing-system : lando
Note that the gdb variant excludes the unwinder tests for now. They require more fixups that I did not want to delve into for the automated test.
Differential Revision: https://phabricator.services.mozilla.com/D54235
--HG--
extra : moz-landing-system : lando
Right now we only detect `onCrash` on mochitests/reftests and `onKill` on junit
tests.
This change makes it so we wait for both on every type of test.
Differential Revision: https://phabricator.services.mozilla.com/D57895
--HG--
extra : moz-landing-system : lando
When an ActiveData query returns HTTP 200 but no data, treat that as a permanent condition:
Do not retry. I expect that will be the case for some test-info queries for reftests
until reftest test names are normalized.
Differential Revision: https://phabricator.services.mozilla.com/D57892
--HG--
extra : moz-landing-system : lando
Changes:
These tests have no clearly defined owners - the person that worked on this doesn't even have a last active date. We've seen, in other reftests, scrollbar related pixel differences so I'm inclined to believe that also plays a role here.
Mark these tests as expected failures on ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D57901
--HG--
extra : moz-landing-system : lando