Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 300105f8996dbbd074b3ca9b2d3a3aaaa9d00c40
https://github.com/WebKit/WebKit/commit/300105f8996dbbd074b3ca9b2d3a3aaaa9d00c40
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-13 (Wed, 13 May 2026)
Changed paths:
M Source/WebKit/UIProcess/mac/WebViewImpl.mm
M Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/WKWebViewMacEditingTests.mm
Log Message:
-----------
REGRESSION(310826@main): Confirming composition results in beep and initiates
a search on google.com
https://bugs.webkit.org/show_bug.cgi?id=314752
rdar://176851109
Reviewed by Abrar Rahman Protyasha and Wenson Hsieh.
310826@main turned on InputMethodUsesCorrectKeyEventOrder by default and, as
part of the dead-key
double-insertion fix, kept pre-existing logic in WebViewImpl::interpretKeyEvent
that forced
handled = NO whenever the IME's collected commands contained an insertText:
This forcing was wrong
once the preference became the default path for all IMEs, not just
docs.google.com's Devanagari flow.
When a Japanese IME commits a composition (Enter/Space confirm), it calls
insertText: with the final
text and returns handled=YES. With the force:
- UIProcess sent handledByInputMethod=false to the web process.
- In EventHandler::internalKeyEvent, the handledByInputMethod branch was
skipped, so:
* The keydown's windowsVirtualKeyCode was not replaced with
CompositionEventKeyCode (229).
* setIsDefaultEventHandlerIgnored was not called.
This resulted in two user-visible bugs:
a. A deep when confirming candidates - the Enter keydown path went through
the composing branch in
internalKeyEvent which returned keydownResult (false) regardless of
whether keypress handled the
commands. The web process reported handled=false, so
WebViewImpl::doneWithKeyEvent re-sent the
event via [NSApp sendEvent:], and the unhandled keyDown: walked up the
first responder chain,
resulted in a beep sound in some apps.
b. google.com search submit - JS keydown listeners saw the real Enter keyCode
(13) instead of 229,
so scripts in google.com that looked for keyCode of 13 on keydown which
initiates google search
was erroneously triggered.
This PR fixes the root cause with two code changes at UIProcess/WebProcess
boundary:
1. Source/WebKit/UIProcess/mac/WebViewImpl.mm - removed the branch for
setting handled = NO when
hasInsertText is true; The IME's handled=YES now flows through, so
NativeWebKeyboardEvent has
handledByInputMethod=true whenever the IME says it handled the event. The
if (!hasInsertText)
guard on appending additionalCommands remains (so that it still protects
the original dead-key
double-insertion case in the handled=NO branch).
2. Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm -
handleEditingKeyboardEvent now executes
queued commands when event.handledByInputMethod() is true, not just when
there are no text
insertion commands orthe event is Char. This is required because with
handledByInputMethod=YES,
internalKeyEvent returns without dispatching keypress, so the insertText:
command must execute
during didDispatchInputMethodKeydown or else the final text would never be
inserted.
Test:
TestWebKitAPI.WKWebViewMacEditingTests.KeyDownForInputMethodCommitUsesCompositionKeyCode
* Source/WebKit/UIProcess/mac/WebViewImpl.mm:
(WebKit::WebViewImpl::interpretKeyEvent):
* Source/WebKit/WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::handleEditingKeyboardEvent):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/mac/WKWebViewMacEditingTests.mm:
(TestWebKitAPI::TEST(WKWebViewMacEditingTests,
KeyDownForInputMethodCommitUsesCompositionKeyCode)):
Canonical link: https://commits.webkit.org/313212@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
