The delete-surrounding signal of WebKitInputMethodContext and WPEInputMethodContext documents offset and n_chars as characters. WebPage::deleteSurrounding() counts UTF-16 code units, and has done since the signal was added (bug 205716). The two only differ outside the Basic Multilingual Plane, for example with emoji. With the caret after "a😀": - delete-surrounding(-1, 1) deletes nothing: it covers half of the emoji's surrogate pair. - delete-surrounding(-2, 2) deletes the emoji. A delete that would start before the text depends on the code units too: after "a😀", (-4, 4) deletes nothing; after "aa😀", it deletes everything. Two more behaviours are not documented, and input methods rely on them: - The offset is counted from the start of the selection, and the delete can reach into the selection. - A count of 0 moves the caret by offset. Input method code in use counts in different units. wpe-android forwards Android's counts, which are UTF-16 code units, and we know of at least one other embedder that counts UTF-16 code units. The Wayland text-input-v1 backend converts to code points. The text-input-v3 backend passes bytes (bug 326818). Proposal: document UTF-16 code units, the selection start and the zero-count caret move. That matches what WebKit does today and changes no behaviour. Then make the Wayland backends convert to UTF-16 code units. Changing the behaviour to code points would break the embedders that count UTF-16 code units.