Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bdad3ac0ce7807eb1ed9fb8923a8ecb7dc58728d
https://github.com/WebKit/WebKit/commit/bdad3ac0ce7807eb1ed9fb8923a8ecb7dc58728d
Author: Lily Spiniolas <[email protected]>
Date: 2025-10-21 (Tue, 21 Oct 2025)
Changed paths:
M
LayoutTests/editing/selection/ios/tap-to-change-selection-after-accepting-inline-prediction.html
A
LayoutTests/fast/forms/ios/keyboard-restoration-after-element-replacement-expected.txt
A
LayoutTests/fast/forms/ios/keyboard-restoration-after-element-replacement.html
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Log Message:
-----------
Keyboard closes after typing one character in gif search field on x.com
https://bugs.webkit.org/show_bug.cgi?id=298304
rdar://162808064
Reviewed by Abrar Rahman Protyasha.
If the keyboard is hidden and an element is programatically focused during
the same presentation update, allow the keyboard to show again.
Track explicit user dismissals of the keyboard using `_editingEndedWithReason`,
and only restore the keyboard if `_editingEndedWithReason` is false.
These changes were originally intoduced in 299615@main but broke async image
decoding for first tile paint and were reverted in 301564@main. This is because
`WebPageProxy::callAfterNextPresentationUpdate()` was being called every time
`_hideKeyboard` was called, which forces a synchronous image decode. This time
around, we pass `editableChanged` to `_hideKeyboard` so that we only call
`WebPageProxy::callAfterNextPresentationUpdate()` if the editing state actually
changed. Thanks to Wenson Hsieh for this fix.
With these changes, layout test
tap-to-change-selection-after-accepting-inline-prediction.html began to fail
due to it using `<body contenteditable>` as the focused element. When
the body was blurred, focus was restored to the body again, and the keyboard
remained open as a result. The test has been updated to use `<div
contenteditable>`
instead so that the keyboard is correctly dismissed. This issue appears to only
affect the simulator; programmatic keyboard dismissal on a contenteditable body
using `blur()` still works for both software and hardware keyboard.
Test: fast/forms/ios/keyboard-restoration-after-element-replacement.html
*
LayoutTests/editing/selection/ios/tap-to-change-selection-after-accepting-inline-prediction.html:
*
LayoutTests/fast/forms/ios/keyboard-restoration-after-element-replacement-expected.txt:
Added.
*
LayoutTests/fast/forms/ios/keyboard-restoration-after-element-replacement.html:
Added.
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView setUpInteraction]):
(-[WKContentView endEditingAndUpdateFocusAppearanceWithReason:]):
(-[WKContentView _didCommitLoadForMainFrame]):
(-[WKContentView _hideKeyboard:]):
(-[WKContentView
_elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
(-[WKContentView _elementDidBlur]):
(-[WKContentView _hideKeyboard]): Deleted.
Canonical link: https://commits.webkit.org/301887@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
