`searchbar-search-button` includes two `<image>` elements, one of which is aimed to visually communicate that this `overlay` image could expand/collapse the search autosuggest list. This `<hbox>` that has an accessible name but lacks an appropriate interactive role and state, because it functions as a button (not focusable with keyboard because the alternative - `Escape` key - exists and works to collapse the autosuggest list and we do not want to create an additional tab stop for keyboard-only users). This would prevent users of speech-to-text/Voice Control from being able to send a click to it by calling its label and screen reader users and users of other assistive technology would not be able to get to this control via shortcuts like a list of controls, etc.
This issue is similar to the `Go` button on the URL bar resolved in the bug 1864962 and to the `Submit search` button tracked in bug 1871596
To activate the searchbar next to the URL Bar that includes this go button: `about:preferences` > `Search` > `Search Bar` > select `Add search bar in toolbar`.
Depends on D199504
Differential Revision: https://phabricator.services.mozilla.com/D197335
This would allow browser test like `accessible/tests/browser/tree/browser_searchbar.js` to test accessible roles in the Accessibility tree for buttons with `aria-haspopup` attributes.
Depends on D199394
Differential Revision: https://phabricator.services.mozilla.com/D199504
This makes accessing `Manager()` on an IPDL protocol safer, and replaces the
previous ActorLifecycleProxy reference, which would only keep the manager alive
until IPDL drops its reference.
Unfortunately this introduces some leaks due to reference cycles, which will be
fixed in follow-up parts.
Differential Revision: https://phabricator.services.mozilla.com/D198624
If we send an Android ACCESSIBILITY_FOCUSED event because of a content
update (ie. scrolling to anchor or DOM selection changes) we should not
scroll the accessible into view. We should assume the content is being
brought into view by itself.
Testing: We already have tests to show that we scroll an accessible into
view when navigating content, testing for the inverse (that the scroll
is done by other means and NOT a11y) is very hard.
Differential Revision: https://phabricator.services.mozilla.com/D199433
Extend a bit the test for dynamic changes to content-visibility, adding
the following checks:
* If there are text descendants in the content-visibility subtree,
make sure they are created when switching to auto ; and removed
when switching back to hidden.
* If there is a content-visibility: hidden or a visibility: hidden
descendant, make sure pruning still applies when switching to
auto.
* If there is a shadow host in the content-visibility subtree,
make sure that shadow subtree is properly updated when
content-visibility changes.
Differential Revision: https://phabricator.services.mozilla.com/D196964
setBoolPref has a persistent effect for the rest of the test run (potentially
affecting the behavior of other prefs), so we don't want to use
that. This test is currently failing when run in test-verify mode as a result
of this. With pushPrefEnv, the test will properly undo its pref-modification
when it completes.
Note: I'm moving the pref-toggle statement inside of a function so that I can
use the ergonomic `await` syntax. This is still essentially right at the start
of the test, since `doTests` is the main function here.
Differential Revision: https://phabricator.services.mozilla.com/D197830
The methods are in `nsCaret`, `nsFrameSelection` and `dom::Selection`. That
makes harder to read, and they are called each other, so, they are reused for
different purpose. Therefore, it must be better to move them into a new class.
Then, the name differences may become more unclear. If you think so, feel free
to request renaming some methods of them.
Differential Revision: https://phabricator.services.mozilla.com/D197288
ContentRemoved recursively walks both AllChildrenIterator and direct DOM children.
In addition, we might get duplicate notifications from DOM and layout, plus PruneOrInsertSubtree might do a recursive walk and it too calls ContentRemoved.
To avoid this duplicate processing, keep a set of removed DOM nodes on the DocAccessible which we clear after mutation events are processed.
Differential Revision: https://phabricator.services.mozilla.com/D196707
std::sort used by nsTArray::Sort expects the comparator to be tolerant
for being called to compare the very same element with itself.
Differential Revision: https://phabricator.services.mozilla.com/D195482
We don't normally create an Accessible for <foreignObject>.
However, if there's an ARIA role or similar, we forceably create one.
Previously, if we ever did this for an SVG element, we would use an AccessibleWrap, which doesn't support HyperText.
This is normally correct because most SVG elements can't contain text.
However, a <foreignObject> can most definitely contain text, so we must use HyperTextAccessible.
This fixes assertions and text attributes.
Differential Revision: https://phabricator.services.mozilla.com/D195387
This is just a "belt-and-suspenders" invariant tightening. Shouldn't impact
behavior at all, assuming that we don't call methods on NotificationController
objects that have been nerfed with Shutdown().
Differential Revision: https://phabricator.services.mozilla.com/D195321
If these assertions somehow fail, then we are probably doomed to crash anyway.
The new release assertions just make it so we'll crash in a controlled way,
with a more actionable backtrace, closer to the problem-spot.
This patch also removes one mDocument null-check that's becoming redundant
since it follows a release-assert that would make us abort if the pointer is
null.
Differential Revision: https://phabricator.services.mozilla.com/D195042
We can sometimes reach the code that this patch is touching, just we've been
shutdown (as can be seen by the fact that we have a null mDocument pointer); in
that case, it's problematic for us to be assigning 'mObservingState' here. The
mObservingState assignment is meant to be *undoing* the temporary assignments
earlier in the function, but in this post-Shutdown situation, it's actually
causing us to forget that we already unregistered as a refresh observer, in a
nested stack level's call to Shutdown().
I think this one place is the only mObservingState assignment that's got this
problem. The other mObservingState assignments should all be OK (they don't
need a "have we shut down" check), because they're all either:
a) modifying mObservingState to record an actual change that we just made to
our RefreshDriver registration,
...or:
b) immediately adjacent to code that dereferences mDocument, implying that
mDocument is known-to-be-non-null at that point, which means we know we haven't
been Shutdown.
This patch unblocks us from adding a release assert in the
NotificationController destructor in the next patch in this series. (Without
this patch, that assertion can be made to fail, via this inadvertent
mObservingState assignment.)
Depends on D195041
Differential Revision: https://phabricator.services.mozilla.com/D195200
This patch is non-functional; it's just adding a debug-only assert, for
documentation and lightweight validation purposes.
As far as I can tell, the asserted condition must hold, since it looks like
this constructor is only invoked via this instantiation of the subclass, which
passes `this` as the aDocument arg (and `this` must trivially be non-null):
https://searchfox.org/mozilla-central/rev/12ea2c521cdd071a6d25b0894f31f8f23b18b76a/accessible/generic/DocAccessible.cpp#422
This assertion makes it easier to reason about the usages of this member-var.
There are lots of checks for whether mDocument is nullptr, and it's useful to
know that it'll always be non-null to begin with (though it becomes null
eventually, as part of teardown, when NotificationController::Shutdown is
called).
Differential Revision: https://phabricator.services.mozilla.com/D195041
If these assertions somehow fail, then we are probably doomed to crash anyway.
The new release assertions just make it so we'll crash in a controlled way,
with a more actionable backtrace, closer to the problem-spot.
This patch also removes one mDocument null-check that's becoming redundant
since it follows a release-assert that would make us abort if the pointer is
null.
Depends on D195041
Differential Revision: https://phabricator.services.mozilla.com/D195042
This patch is non-functional; it's just adding a debug-only assert, for
documentation and lightweight validation purposes.
As far as I can tell, the asserted condition must hold, since it looks like
this constructor is only invoked via this instantiation of the subclass, which
passes `this` as the aDocument arg (and `this` must trivially be non-null):
https://searchfox.org/mozilla-central/rev/12ea2c521cdd071a6d25b0894f31f8f23b18b76a/accessible/generic/DocAccessible.cpp#422
This assertion makes it easier to reason about the usages of this member-var.
There are lots of checks for whether mDocument is nullptr, and it's useful to
know that it'll always be non-null to begin with (though it becomes null
eventually, as part of teardown, when NotificationController::Shutdown is
called).
Depends on D195040
Differential Revision: https://phabricator.services.mozilla.com/D195041
This is needed in order to support find in page on Android using remote caret events instead of virtual cursor change events.
Depends on D192641
Differential Revision: https://phabricator.services.mozilla.com/D192642
James Teh
Anna Yeddi
Tom Marble
Sandor Molnar
Stanca Serban
Nika Layzell
Eitan Isaacson
Brad Werth
Morgan Rae Reschenberg
Tom Schuster
Frédéric Wang
Daniel Holbert
Masayuki Nakano
Emilio Cobos Álvarez
Ziran Sun
Norisz Fay
Jens Stutte
Randell Jesup
Joel Maher
Natalia Csoregi
Butkovits Atila