commit 683e3050cf17d659a00274763e282938ffefafdd
author Aaron Leventhal <aleventhal@google.com> Tue Feb 20 16:57:09 2024
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Feb 20 16:57:09 2024
tree 26b33ba810ba7704cf6c619af994aedaf7a0f669
parent 24901efae5b2d2ca097dc9068bdb9a2d1c97c54a

[A11y] Don't do any work when AXTreeCombiner combines only 1 tree

* tl;dr
This is a workaround in order to fix AXAssistantStructure, which
currently produces incorrect results for contenteditable values when AXTreeCombiner renumbers the nodes. It is also needed to unblock "stable ids" and per-tab auto disable accessibility.

* Description of bug
The value of a contenteditable node is the combined text of all
descendants, with newlines added for readability. AXAssistantStructure
currently produces incorrect results, because AXTreeCombiner renumbers
the tree, and when AXPosition looks up nodes by number, it gets the
wrong nodes.

The bug can already be seen in current results for the test
org.chromium.content.browser.accessibility.WebContentsAccessibilityTreeTest#test_ariaTextboxWithAriaTextboxChild. The current test expectations
are incorrect. If you look at the expected output file
(content/test/data/accessibility/aria/aria-textbox-with-aria-textbox-child-expected-android-assist-data.txt), the parent node should
have the same text property value as the child, "Baz".
Unfortunately, it uses another child "Bar" in its place (and the "Bar"
parent ends up using "Baz"). IOW, the parents have swapped children
for purposes of the contenteditable value computation.

* Cause of bug
The cause of this is that when AXPosition, which is used to aggregate
the descendant text, stores a node it uses an AXTreeID/AXNodeID pair.
However, in order to turn this into an AXNode, the AXTreeManagerMap is
used, but the AXTreeID being used is still points to the original tree
that was not renumbered.

* Workaround
This CL provides a workaround but does not fix the root problem.
The workaround is to fix the majority of cases (and those used in
tests), by having AXTreeCombiner be a noop in cases where there is
only one tree. Unfortunately, this means the bug would still exist
in a page with iframes.

* Long term fix
The long term way to fix this is to make AXPosition store weak pointers
to AXNodes, rather than AXTreeID/AXNodeID pairs. It also has
performance benefits. That has been
landed and reverted several times, because of issues with
text interfaces in UIA. See CL:5300830 for more information.

* Other possibilities
Another fix is to consider whether contenteditable values need to
aggregate the value of their descendants for use with snapshots or
AXTreeCombiner. Consumers of these APIs are unlikely to need the
text to be repeated, and in fact it would be a potential performance
fix as well.

Bug: none
Change-Id: Ia90e4e0a2b29f64c7fabbd6063e16e5c08e69245
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5301248
Reviewed-by: Mark Schillaci <mschillaci@google.com>
Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1262735}