Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ec3a7ab1590bf34a2d0461690772437d3d1a2d7b
https://github.com/WebKit/WebKit/commit/ec3a7ab1590bf34a2d0461690772437d3d1a2d7b
Author: Dominic Mazzoni <[email protected]>
Date: 2026-07-24 (Fri, 24 Jul 2026)
Changed paths:
A
LayoutTests/accessibility/mac/textarea-value-selection-consistency-on-valuechange-expected.txt
A
LayoutTests/accessibility/mac/textarea-value-selection-consistency-on-valuechange.html
M Source/WebCore/accessibility/AXCoreObject.cpp
M Source/WebCore/accessibility/AXCoreObject.h
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/isolatedtree/AXIsolatedTree.cpp
Log Message:
-----------
AX: value and selection for an editable text field aren't updated together in
isolated tree
https://bugs.webkit.org/show_bug.cgi?id=320074
rdar://182995716
Reviewed by Tyler Wilcock.
When text is inserted into a text control, VoiceOver responds to the
value-changed notification and could observe the updated value but a stale caret
position. There were two root causes.
First, the tree-level selection (the selected text marker range) is
updated on the selection-change channel, which runs after the
value-changed notification is delivered. A client responding to the
value change therefore saw a selection from before the edit. The fix is to
push the current selection alongside the value change for text
controls, so both are delivered together. The live selection is
already up-to-date at this point, so no extra recomputation is needed.
Second, the node-level selection (AXProperty::SelectedTextRange) could
be reverted on the accessibility thread. A value change queues a full
node update, which is transported to the isolated tree as an "append"
carrying a complete, freshly recomputed copy of the node (including
its selection). Separately, selection changes queue a
SelectedTextRange property update, debounced by ~100ms to coalesce
rapid pure-selection changes such as drag-select. When a debounced
update from one keystroke and the full node append from the next
keystroke land in the same snapshot, the reader thread applies all
appends before all property changes, so the older debounced selection
was applied last and clobbered the fresh one. There is already
same-cycle dedup for this in processQueuedNodeUpdates() (a property
update is skipped when a full node update is pending for the same
object); the debounce simply moves the two into different cycles,
defeating it. queueChange() now drops an already-queued
SelectedTextRange update for an object when committing an append for
it, extending that dedup across cycles. Updates queued after the
append are preserved, keeping last-writer-wins by queue order intact.
The debounce is left in place for its original purpose. Value changes
are naturally throttled by typing speed, whereas pure selection
changes are not, so coalescing still matters for the latter.
Test: accessibility/mac/textarea-value-selection-consistency-on-valuechange.html
*
LayoutTests/accessibility/mac/textarea-value-selection-consistency-on-valuechange-expected.txt:
Added.
*
LayoutTests/accessibility/mac/textarea-value-selection-consistency-on-valuechange.html:
Added.
* Source/WebCore/accessibility/AXCoreObject.cpp:
(WebCore::AXCoreObject::isTextControl const):
(WebCore::AXCoreObject::isTextControl):
* Source/WebCore/accessibility/AXCoreObject.h:
* Source/WebCore/accessibility/AXObjectCache.cpp:
(WebCore::AXObjectCache::updateIsolatedTree):
* Source/WebCore/accessibility/isolatedtree/AXIsolatedTree.cpp:
(WebCore::AXIsolatedTree::queueChange):
Canonical link: https://commits.webkit.org/317898@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
