The DocProxyAccessibleWrap for an OOP iframe document is always created before we know its parent.
Previously, this resulted in the document getting an id of -1, which is only valid for the root document.
It also broke subsequent assumptions once the parent was set later.
Because we don't have the parent in this case, we can't add the document's id to its parent's hash table.
To deal with this, we no longer add any document to its parent's hash table.
Instead, when finding an accessible by id, we just check the id of each child document before checking that child document's hash table.
Differential Revision: https://phabricator.services.mozilla.com/D81959
The IPC docs of the first/last nodes are not guaranteed to exist. This
could happen early on when the child docs are still hanging and have not
yet been processed in the NotificationController.
Differential Revision: https://phabricator.services.mozilla.com/D81883
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
Android does not currently have anything similar to a 'required' state
to indicate that a field or input is required before submission. In this
patch we append a localized "required" string onto the node's hint.
The hint typically has the description of the node. If the node is an
entry the hint will have its label followed by the description.
Differential Revision: https://phabricator.services.mozilla.com/D65215
--HG--
extra : moz-landing-system : lando
If a keyboard-focused accessible is removed, the caret jumps to its
nearest ancestor. To avoid arbitrary accessibility focus moves, ignore
caret events that have no selection and are not focusable items.
Differential Revision: https://phabricator.services.mozilla.com/D63541
--HG--
extra : moz-landing-system : lando
This allows `performAction` to immediately return false if a boundary is
reached and allow TalkBack to navigate past the web view.
Change viewport cache listener to reorder since it should catch all tree
mutations in the document.
Differential Revision: https://phabricator.services.mozilla.com/D63117
--HG--
extra : moz-landing-system : lando
Chrome prunes the subtrees of links and headings (with single text leaf
children) and we mimic this in Gecko. The problem is that sometimes a
heading can be a child of a link, and it would be impossible to reach
when navigating by headings.
The main reason we mimiced chrome is because we would getthe name of the
node and its subtree uttered, so you would hear the name of the node
twice. By using contentDescription we can suppress the subtree from
TalkBack's utterance and preserve the node's children for heading
navigation.
Differential Revision: https://phabricator.services.mozilla.com/D61766
--HG--
extra : moz-landing-system : lando
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
For paragraphs, divs, spans, etc., a11y focus on Android goes to text leaf Accessibles, rather than to the HyperTextAccessible container.
This does make sense, as these containers frequently embed other content, so the text needs to be reachable as a separate item.
However, previously, performing text navigation on these text leaf Accessibles returned the HyperTextAccessible parent.
This isn't supported by Talkback, and even if it were, it causes other problems; e.g. a11y focus being lost if the user was focused on a child other than the first child of such a container.
Therefore, if text navigation was performed on a text leaf Accessible, we now return a result within the text leaf Accessible if possible, rather than the HyperTextAccessible.
1. Make AccessibleWrap::GetTextContents support text leaf Accessibles (for both local and remote proxied Accessibles).
This is used when providing text for text traversal events.
2. When navigating text on Android, we use Pivot::Next/PrevText.
However, this will always return a HyperTextAccessible, even when starting on a text leaf.
Therefore, if the result from Pivot::Next/prevText resides entirely within the same text leaf, translate the offsets from the HyperTextAccessible so they're relative to the text leaf and return the text leaf.
3. Pivot::Next/PrevText already supported starting from a text leaf Accessible.
However, they ignored the offsets, which meant that navigating from a text leaf would always navigate to the start/end of the text leaf.
Now, if a text leaf is passed to Pivot::Next/PrevText, the offsets (if specified) are translated to the HyperTextAccessible parent first.
4. Adjust the existing character/word/line tests so they ensure that navigation returns the node that has a11y focus; i.e. the text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D57269
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
ARIA role="combobox" gets a Gecko role of EDITCOMBOBOX.
However, there are two kinds of ARIA comboboxes:
1. ARIA 1.0 comboboxes are contentEditable. Text is entered into the combobox itself.
2. ARIA 1.1 comboboxes are not contentEditable. Instead, they have a textbox child into which text is entered.
On Android, traversal skipped EDITCOMBOBOX Accessibles altogether.
This meant that while 1.1 comboboxes were accessible (because we'd walk inside and land on the textbox), 1.0 comboboxes were not.
We still don't want to land on 1.1 comboboxes because the container isn't useful to the user.
Therefore, only stop on EDITCOMBOBOX Accessibles which are editable.
Differential Revision: https://phabricator.services.mozilla.com/D55224
--HG--
extra : moz-landing-system : lando
Gecko's link role is used even for <a> elements without href or onclick.
Actionable links are indicated using the linked state.
However, Android doesn't have a concept equivalent to the linked state.
Thus, on Android, we must not expose an element as a link at all if it does not have the linked state.
Differential Revision: https://phabricator.services.mozilla.com/D55207
--HG--
extra : moz-landing-system : lando
We noticed a handful of linker errors when building with other build optimization flags -Os, -O2, and -O3 instead the default, -Oz.
(see Bug 1591725).
This change is intended to be 0-impact on functionality -- simply resolving the linker errors.
Differential Revision: https://phabricator.services.mozilla.com/D51312
--HG--
extra : moz-landing-system : lando
I don't have a test case for this crash, but the stack suggests the frame is null.
This can certainly happen for display: contents.
Differential Revision: https://phabricator.services.mozilla.com/D51560
--HG--
extra : moz-landing-system : lando
The GECKOBUNDLE macros are useful to more than just a11y code, so let's move them into the jni package so that all jni consumers may drink of their sweet nectar.
Differential Revision: https://phabricator.services.mozilla.com/D30585
--HG--
extra : moz-landing-system : lando
This patch makes accessible module use `mozilla::PresShell` directly rather
than via `nsIPresShell`. Additionally, renames `DocAccessible::PresShell()`
to `DocAccessible::PresShellPtr()` for avoiding conflict with using
`PresShell` in it and its sub classes.
Differential Revision: https://phabricator.services.mozilla.com/D26663
--HG--
extra : moz-landing-system : lando
This patch marks some methods of nsCoreUtils which are found at writing the
following patches, as `MOZ_CAN_RUN_SCRIPT`.
Due to bug 1543294, some of them are marked as `MOZ_CAN_RUN_SCRIPT_BOUNDARY`
because `MOZ_CAN_RUN_SCRIPT` requires to change base class, but that's
other licenses header or used in our code too many places.
Differential Revision: https://phabricator.services.mozilla.com/D26926
--HG--
extra : moz-landing-system : lando
Eitan Isaacson
James Teh
Simon Giesecke
Narcis Beleuzu
Morgan Reschenberg
Aaron Klotz
Botond Ballo
Csoregi Natalia
Kannan Vijayan
Emilio Cobos Álvarez
Andrew Creskey
Noemi Erli
Boris Zbarsky
J.C. Jones
Ryan Hunt
Masayuki Nakano