Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f716dbb1d140cb25e91af82f263a1e61ea5d6b21
https://github.com/WebKit/WebKit/commit/f716dbb1d140cb25e91af82f263a1e61ea5d6b21
Author: Wenson Hsieh <[email protected]>
Date: 2026-02-05 (Thu, 05 Feb 2026)
Changed paths:
A
LayoutTests/fast/forms/ios/zoom-to-reveal-focused-element-after-delay-expected.txt
A LayoutTests/fast/forms/ios/zoom-to-reveal-focused-element-after-delay.html
M LayoutTests/resources/ui-helper.js
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
M Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl
M Tools/TestRunnerShared/UIScriptContext/UIScriptController.h
M Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.h
M Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm
M Tools/WebKitTestRunner/ios/TestControllerIOS.mm
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h
M Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm
Log Message:
-----------
[iOS] Focused element is not revealed if the
focusRequiresStrongPasswordAssistance delegate takes too long
https://bugs.webkit.org/show_bug.cgi?id=307081
rdar://169666776
Reviewed by Ryosuke Niwa and Abrar Rahman Protyasha.
In the case where the WebKit client defers the call to
`-_continueElementDidFocus:` via the input
delegate method
`-_webView:focusRequiresStrongPasswordAssistance:completionHandler:` until after
the first editor state update after element focus arrives in the UI process, we
end up never calling
`-_zoomToRevealFocusedElement` (which is responsible for zooming and centering
the newly focused
element). The sequence of events is:
1. Element did focus is called.
2. Editor state arrives.
3. Element did focus continues (after the client invokes the completion
handler).
...which means `m_waitingForPostLayoutEditorStateUpdateAfterFocusingElement` is
stuck at `true`
after step (3). To fix this, we set
`m_waitingForPostLayoutEditorStateUpdateAfterFocusingElement`
*before* calling into the delegate, and then defer until the next `EditorState`
update upon step (3)
only if the editor state update hasn't arrived yet; otherwise, we just zoom to
the focused element
immediately, after showing the keyboard.
Test: fast/forms/ios/zoom-to-reveal-focused-element-after-delay.html
*
LayoutTests/fast/forms/ios/zoom-to-reveal-focused-element-after-delay-expected.txt:
Added.
* LayoutTests/fast/forms/ios/zoom-to-reveal-focused-element-after-delay.html:
Added.
Add a test to simulate the race condition above by forcing a hard-coded 250 ms
delay in the input
delegate method.
* LayoutTests/resources/ui-helper.js:
(window.UIHelper.setShowKeyboardAfterElementFocusDelay):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView
_elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
(-[WKContentView
_continueElementDidFocus:requiresStrongPasswordAssistance:focusedElementInfo:activityStateChanges:restoreValues:]):
Implement the main fix here — see above for more details.
* Tools/TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
* Tools/TestRunnerShared/UIScriptContext/UIScriptController.h:
(WTR::UIScriptController::setShowKeyboardAfterElementFocusDelay):
* Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.h:
* Tools/WebKitTestRunner/cocoa/TestRunnerWKWebView.mm:
(-[TestRunnerWKWebView
_webView:focusRequiresStrongPasswordAssistance:completionHandler:]):
* Tools/WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.h:
* Tools/WebKitTestRunner/ios/UIScriptControllerIOS.mm:
(WTR::UIScriptControllerIOS::setShowKeyboardAfterElementFocusDelay):
Add test runner infrastructure to set a hard-coded delay before allowing
element focus to continue.
Canonical link: https://commits.webkit.org/306897@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
