Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: bca963b6a79c3e680f9766769d796daf067e1540
https://github.com/WebKit/WebKit/commit/bca963b6a79c3e680f9766769d796daf067e1540
Author: Wenson Hsieh <[email protected]>
Date: 2026-01-15 (Thu, 15 Jan 2026)
Changed paths:
A
LayoutTests/editing/input/ios/compose-accent-with-hardware-keyboard-when-preventing-keydown-expected.txt
A
LayoutTests/editing/input/ios/compose-accent-with-hardware-keyboard-when-preventing-keydown.html
M Source/WTF/wtf/text/CharacterProperties.h
M Source/WebCore/editing/Editor.cpp
M Source/WebCore/editing/Editor.h
M Source/WebCore/page/EventHandler.cpp
Log Message:
-----------
[iPadOS] duckduckgo.com, docs.google.com: typing accented characters with
dead keys breaks text input
https://bugs.webkit.org/show_bug.cgi?id=305578
rdar://167230597
Reviewed by Abrar Rahman Protyasha.
On iOS, inserting accented characters using dead keys only sets marked text
upon the initial key
press of `Option + {e|i|u}`, etc. The second character which actually inserts
the dead key isn't
actually handled by system IME, but rather gets dispatched as normal text entry
(but with a modified
character, like é or ü, as the input text). In contrast, on macOS, both the
first and second
key presses are handled by system IME.
On websites like duckduckgo.com or docs.google.com, which call
`preventDefault()` on the `keydown`
event during IME, this causes text input to be prevented when using dead keys
on iOS, but not on
macOS (or in other browser engines). As a result, this breaks all text input
when using a hardware
keyboard on iOS if the website prevents `keydown`, after pressing `Option` and
any dead key modifier
like e, i, u, etc.
To fix this, we align the behavior of dead keys when using a hardware keyboard
on iOS to other
engines (as well as macOS WebKit) by forcing the key event to be interpreted by
the system in the
case where the IME range is a single modifier (e.g. "´", "¨", "ˆ") based on the
editor's active
composition range, even if the `keydown` was prevented. Note that because the
`isComposing()` flag
is set, we will still avoid dispatching `keypress` in this scenario (which is
consistent with macOS
as well as other browsers).
Test:
editing/input/ios/compose-accent-with-hardware-keyboard-when-preventing-keydown.html
*
LayoutTests/editing/input/ios/compose-accent-with-hardware-keyboard-when-preventing-keydown-expected.txt:
Added.
*
LayoutTests/editing/input/ios/compose-accent-with-hardware-keyboard-when-preventing-keydown.html:
Added.
Add a layout test to exercise the change, by typing several different accented
(or otherwise
modified) characters with a hardware keyboard.
* Source/WTF/wtf/text/CharacterProperties.h:
(WTF::isLetterOrSymbolModifier):
* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::confirmComposition):
(WebCore::Editor::compositionText const):
(WebCore::Editor::hasDeadKeyComposition const):
Add a helper method to determine whether the existing IME composition range
consists of a single
modifier character, inserted by a dead key.
* Source/WebCore/editing/Editor.h:
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::internalKeyEvent):
See above for more details.
Canonical link: https://commits.webkit.org/305672@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
