Do not merge semantics configs anchoring different traversal parents - #190344

Fixes #182444

Draft: the CLA is not signed yet. Opening early so the analysis is on the record; I'll mark it ready once that's done.

The bug

SemanticsConfiguration.isCompatibleWith guards _traversalChildIdentifier but not _traversalParentIdentifier:

if (_traversalChildIdentifier != other._traversalChildIdentifier) {
  return false;
}

So two sibling anchors — for example two adjacent Tooltips, each backed by its own OverlayPortal — are considered mergeable. absorb then keeps only the first identifier, because it assigns with ??=:

if (_traversalChildIdentifier == null) {
  _traversalParentIdentifier ??= child._traversalParentIdentifier;
}

The second one is silently dropped. Since that identifier is the only handle its traversal children have to find their parent, the second portal's overlay child resolves no traversal parent (traversalParent = -1) and is serialized as an orphan — no node claims it as a child.

On Windows ui::AXTree::Unserialize then rejects the entire update with N will not be in the tree and is not the new root (ax_tree.cc:1346). After that the accessibility tree stays frozen for the life of the window, so NVDA keeps presenting a stale screen and the app becomes untraversable.

Note the engine cannot defend against this: accessibility_bridge.cc copies children_in_traversal_order straight into AXNodeData::child_ids without validating or pruning, so an inconsistent SemanticsUpdate is passed through as-is.

Why a ListView is needed to reproduce

Each ListView item is wrapped in an IndexedSemantics, which absorbs everything it contains into a single node — that is what forces the two anchors together. The same two anchors in a bare Row stay separate, which is why the issue only reproduces inside a list. Neither Tooltip nor hovering is actually required: two bare Semantics(traversalParentIdentifier: ...) widgets in a list item are enough.

This also corrects the root-cause analysis in the issue itself, which attributes the bug to detachment ordering during sendSemanticsUpdate. That hypothesis is not what happens here — the identifier never reaches a node in the first place. The two related fixes that landed in May (#186118, #186826) do not cover this case; I verified the issue still reproduces on master.

The fix

Refuse to merge two configurations that each anchor a different, non-null traversal parent. The guard is deliberately narrower than the traversalChildIdentifier one above it: a plain != would also stop an anchor from merging with ordinary unannotated content, which would change tree shape broadly for no benefit.

Tests

Added sibling traversal parents are not merged into a single node in packages/flutter/test/widgets/semantics_test.dart, next to the existing grafting tests. It fails without the fix:

Expected: contains all of ['A', 'B']
  Actual: ['A']

and passes with it.

Also verified against the issue's own reproduction, using a harness that replays the engine's bridge contract in Dart (every serialized node must end up reachable from the root): fails on stable 3.44.8 and on unpatched master with the exact production error text, passes with the fix, including a 5-tooltip variant.

No regressions: test/widgets (7174 passed), test/material (7973 passed), plus test/semantics, test/widgets/semantics_test.dart, test/widgets/overlay_portal_test.dart and test/material/tooltip_test.dart.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities. This change was developed with AI assistance (disclosed via Co-Authored-By on the commit); the analysis, the reproduction and the test results above were verified by running them.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.