Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 09476ede43d960040aa4b9c4633043c16566f2b5
https://github.com/WebKit/WebKit/commit/09476ede43d960040aa4b9c4633043c16566f2b5
Author: Tyler Wilcock <[email protected]>
Date: 2026-09-18 (Fri, 18 Sep 2026)
Changed paths:
A
LayoutTests/accessibility/ios-simulator/assistive-technology-focus-does-not-present-input-view-expected.txt
A
LayoutTests/accessibility/ios-simulator/assistive-technology-focus-does-not-present-input-view.html
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
M Source/WebCore/accessibility/AccessibilityObject.cpp
M Source/WebCore/dom/FocusOptions.h
M Source/WebKit/Shared/FocusedElementInformation.h
M Source/WebKit/Shared/FocusedElementInformation.serialization.in
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
AX: select / date input pickers are automatically expanded with iOS VoiceOver
after swiping right from a text field, which is wrong and confusing
https://bugs.webkit.org/show_bug.cgi?id=324452
rdar://187693048
Reviewed by Chris Fleizach.
On iOS a form control's input view -- the software keyboard, a select's picker,
a
date or color picker -- is presented as a side effect of focusing the control,
because on a touch screen the tap that focuses it is also the gesture that
activates it. -[WKContentView _elementDidFocus:] therefore looks for evidence
that
the user drove the focus change, and one of the things it accepts is that some
element was already focused: continuity for a user moving between fields inside
an
editing session that is already underway.
That cannot distinguish a user moving between fields from an assistive
technology
moving focus because the user swiped to the next element. The result is a picker
opening for a control the user only moved their cursor to, and only when coming
from a control they had been editing.
Mark focus that follows an assistive technology's cursor, and don't let the Auto
policy present an input view for it.
AccessibilityRenderObject::setSelectedTextRange() also focuses, and is
intentionally
excluded from setting the new preventInputViewPresentation flag, as it runs
while
the user is editing rather than navigating.
*
LayoutTests/accessibility/ios-simulator/assistive-technology-focus-does-not-present-input-view-expected.txt:
Added.
*
LayoutTests/accessibility/ios-simulator/assistive-technology-focus-does-not-present-input-view.html:
Added.
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::setFocused):
* Source/WebCore/accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::pressPreservingFocus):
* Source/WebCore/dom/FocusOptions.h:
* Source/WebKit/Shared/FocusedElementInformation.h:
* Source/WebKit/Shared/FocusedElementInformation.serialization.in:
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView
_elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::emitDeferredFocusedElementUpdate):
Canonical link: https://commits.webkit.org/321385@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
