Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4d6958458e261cd50f9769a8c21bfb8f9005c701
https://github.com/WebKit/WebKit/commit/4d6958458e261cd50f9769a8c21bfb8f9005c701
Author: Fujii Hironori <[email protected]>
Date: 2026-10-13 (Tue, 13 Oct 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
Log Message:
-----------
[GTK][WPE] Calling blur() and then focus() on the focused element in the same
task notifies the input method of a focus out and in
https://bugs.webkit.org/show_bug.cgi?id=327375
Reviewed by Carlos Garcia Campos.
Some pages call blur() and then focus() on the focused element in the same
task. google.com does it right after its search field gets the focus, and
Google Sheets does it when an edit of a cell is committed. blur() moves the
focus to the viewport and focus() moves it back, so the page gets blur and
focus events, but by the end of the task the same element has the focus
again.
WebPage::setInputMethodState() sent no state for the blur and then the state
of the element again for the focus, which InputMethodFilter turned into
notify_focus_out followed by notify_focus_in on the input method context. An
on-screen keyboard can close and open again in between.
Cocoa avoids this by holding back ElementDidBlur until the next run loop
iteration in WebPage::elementDidBlur(), and dropping it if the element is
focused again. Do the same for the input method state: when there is a
recently blurred element, setInputMethodState() doesn't reset the state, and
the run loop callback of elementDidBlur() does it unless the element was
focused again.
Calling blur() on an element and then focus() on another one in the same task
is now like moving the focus directly: the embedder gets the state of the new
element, if it differs, without a focus out and in.
When the focused element is removed from the document, the focused area of
the document becomes the viewport without a blur event. WebKit calls
ChromeClient::elementDidBlur() but not EditorClient::setInputMethodState() in
that case, so the input method context stayed enabled after the element was
gone. The run loop callback now resets the state in that case too.
Tests:
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::elementDidBlur):
* Source/WebKit/WebProcess/WebPage/glib/WebPageGLib.cpp:
(WebKit::WebPage::setInputMethodState):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/glib/TestInputMethodContext.cpp:
(testWebKitInputMethodContextFocusBlurRefocus):
(testWebKitInputMethodContextRemoveFocusedElement):
(testWebKitInputMethodContextBlurRefocusInteraction):
(beforeAll):
Canonical link: https://commits.webkit.org/323652@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
