NEW326818
[WPE] Wayland text-input-v3 delete-surrounding lengths are bytes, but are used as characters 
https://bugs.webkit.org/show_bug.cgi?id=326818
Summary [WPE] Wayland text-input-v3 delete-surrounding lengths are bytes, but are use...
Simon Pena
Reported 2026-10-08 07:39:36 PDT
The text-input-v3 delete_surrounding_text event gives before_length and after_length in bytes. WPEInputMethodContextWaylandV3 passes them on unchanged in the delete-surrounding signal, which WebKit counts in characters. With text that is not ASCII before or after the cursor, more text is deleted than the input method asked for. For example, a request to delete one Japanese character before the cursor (3 bytes) deletes three characters. text-input-v1 does not have this problem: WPEInputMethodContextWaylandV1 converts its byte offsets with the surrounding text it keeps. Found by reading the code and the protocol; not reproduced yet. Bug 326573 fixes the pre-edit cursor offsets in the same file.
Attachments
Add attachment proposed patch, testcase, etc.
Simon Pena
Comment 1 2026-10-13 09:23:39 PDT
Measured with an API test (WebKitInputMethodContext, today's main): with the caret after "aé", delete-surrounding(-2, 2) deletes both "a" and "é". That is what this backend sends when the input method deletes "é", because "é" is 2 bytes in UTF-8. So any non-ASCII character before the caret makes it delete too much, not just emoji. Which units the signal should use is bug 327412. WebKit counts UTF-16 code units today, so the conversion here should probably go to UTF-16 code units rather than characters.
Note You need to log in before you can comment on or make changes to this bug.