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
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Also add an IsElement check in GetElementFromPoint in the APZ code since I think
the element cast is unsound in presence of Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D14355
--HG--
extra : moz-landing-system : lando
