The text-input-v3 preedit_string event gives cursor_begin and cursor_end in bytes, with -1 meaning the cursor is hidden. The protocol does not say that cursor_begin comes first. WPEInputMethodContextWaylandV3 passes both 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 position and the underline are wrong. When cursor_end is before cursor_begin, the underline range is reversed, and painting it hits an assertion in builds with assertions on. Steps (GNOME 46.0, Japanese input method): 1. Open a page with a text field in WPE MiniBrowser. 2. Type "a" with the input method in Hiragana mode. Mutter sends the text "あ" (3 bytes) with cursor_begin=3 and cursor_end=1. Mutter before 47 sent cursor_end in characters (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3845). Expected: no assertion; the cursor is after "あ". Actual: ASSERTION FAILED: start <= destination in RenderText::stringView(), called from TextBoxPainter::paintCompositionUnderline().