Bug 326818
| Summary: | [WPE] Wayland text-input-v3 delete-surrounding lengths are bytes, but are used as characters | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Pena <spena> |
| Component: | WPE WebKit | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=326573 https://bugs.webkit.org/show_bug.cgi?id=326817 https://bugs.webkit.org/show_bug.cgi?id=327412 |
||
Simon Pena
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
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.