Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 64ee64bad41e5d511964c29b8ab00ee77269821a
https://github.com/WebKit/WebKit/commit/64ee64bad41e5d511964c29b8ab00ee77269821a
Author: Nathan Solomon <[email protected]>
Date: 2026-06-24 (Wed, 24 Jun 2026)
Changed paths:
R
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-053-expected.txt
M
LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/exec-command-with-text-editor.tentative_type=text-expected.txt
M
LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/exec-command-with-text-editor.tentative_type=textarea-expected.txt
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
Log Message:
-----------
[iOS] Defer ElementDidFocus IPC to the next rendering update
https://bugs.webkit.org/show_bug.cgi?id=315247
rdar://177468274
Reviewed by Wenson Hsieh.
On iOS, WebPage::elementDidFocus runs layoutIfNeeded() from a JS click handler
dispatched via simulateClick() in order to populate interactionRect for the
ElementDidFocus IPC. But, this is very expensive for form-heavy interactions.
Defer the IPC to the next rendering update. elementDidFocus() now stores the
gesture state into a member variable on WebPage,
ensures the next rendering update is scheduled, and then returns. Utilize
the fact that the next rendering update will already do layoutIfNeeded(). So
when
WebPage::updateRendering() runs during that next rendering update,
Page::updateRendering() has already run its layout pass for the frame so we
send the
IPC message with correct geometry for the focused element while avoiding extra
layoutIfNeeded() calls for each user-gesture-driven focus that would fire before
the next rendering update. This also means we are now sending fewer IPC messages
to the UI Process than before.
Remove and update iOS-specific test baselines that captured existing failures
caused by the
extra layoutIfNeeded() in the iOS focus path. The exec-command
baselines had a FAIL for undo not clearing after .value
assignment on input/textarea inside contenteditable. The content-visibility
ios baseline had an extra newline (for some currently unknown reason) now
matches the generic baseline that matches MacOS baseline as well.
*
LayoutTests/platform/ios/imported/w3c/web-platform-tests/css/css-contain/content-visibility/content-visibility-053-expected.txt:
Removed.
*
LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/exec-command-with-text-editor.tentative_type=text-expected.txt:
*
LayoutTests/platform/ios/imported/w3c/web-platform-tests/editing/other/exec-command-with-text-editor.tentative_type=textarea-expected.txt:
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::completeSyntheticClick):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::executeEditCommandWithCallback):
(WebKit::WebPage::runJavaScriptInFrameInScriptWorld):
(WebKit::WebPage::updateRendering):
(WebKit::WebPage::resetFocusedElementForFrame):
(WebKit::WebPage::elementDidRefocus):
(WebKit::WebPage::elementDidFocus):
(WebKit::WebPage::elementDidBlur):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::requestFocusedElementInformation):
(WebKit::WebPage::focusedElementInformation):
(WebKit::WebPage::focusedElementInformationWithoutLayout):
(WebKit::WebPage::emitDeferredFocusedElementUpdate):
(WebKit::WebPage::flushPendingFocusedElementUpdateIfNeeded):
(WebKit::WebPage::focusTextInputContextAndPlaceCaret):
Canonical link: https://commits.webkit.org/315733@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
