Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f01f6b6394106264db605ce9c5d2914b8e8fb3f4
https://github.com/WebKit/WebKit/commit/f01f6b6394106264db605ce9c5d2914b8e8fb3f4
Author: Simon Pena <[email protected]>
Date: 2026-10-09 (Fri, 09 Oct 2026)
Changed paths:
M Source/WebKit/WPEPlatform/wpe/wayland/WPEInputMethodContextWaylandV3.cpp
Log Message:
-----------
[WPE] Wayland text-input-v3 pre-edit cursor offsets are bytes, but are used
as characters
https://bugs.webkit.org/show_bug.cgi?id=326573
Reviewed by Adrian Perez de Castro.
The text-input-v3 preedit_string event gives cursor_begin and cursor_end in
bytes, with -1 when
the cursor is hidden, and does not say which one comes first. They were passed
on unchanged as the
pre-edit cursor offset and as the range of an underline, which are both counted
in characters.
With text that is not ASCII, the cursor and the underline were in the wrong
place. When cursor_end
was before cursor_begin, the underline range was reversed, and painting it hit
an assertion. Mutter
before 47 sends cursor_end in characters, so with a Japanese input method this
happened on the
first character typed.
Convert both offsets to characters, clamped to the pre-edit text, and put the
ends of the
underline in order. When the cursor is hidden, put it at the end of the
pre-edit.
No new tests: the API tests cannot make a Wayland compositor send pre-edit
events. Checked by hand
in WPE MiniBrowser with GNOME 46.0 and a Japanese input method.
* Source/WebKit/WPEPlatform/wpe/wayland/WPEInputMethodContextWaylandV3.cpp:
(preeditCharacterOffset):
(wpeIMContextWaylandV3GetPreeditString):
Canonical link: https://commits.webkit.org/323196@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
