SUMMARY text-input-v3: kwin does not send empty or null preedit when backspace is pressed after a single character is composed. STEPS TO REPRODUCE 1. With WAYLAND_DEBUG=1 and filtering for text-input-v3 logs, open any app that uses text-input-v3 and focus an input field 2. Switch language to enable IME (e.g. japanese anthy) 3. Enter a character, e.g. 'a' 4. Press backspace OBSERVED RESULT 3. The preedit string is received: ``` zwp_text_input_v3#44.preedit_string("あ", 3, 3) zwp_text_input_v3#44.done(31) ``` 4. Only `done` is received: ``` zwp_text_input_v3#44.done(31) ``` EXPECTED RESULT 3. Should be same as seen 4. Another `preedit` and `done` should be received: ``` zwp_text_input_v3#44.preedit_string("", 0, 0) zwp_text_input_v3#44.done(31) ``` SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.1.4 ADDITIONAL INFORMATION When backspace is pressed after two characters are entered, it correctly sends the new preedit with the single character. In text-input-v1 it does send an empty preedit string when backspace is entered. ``` zwp_text_input_v1#44.preedit_string(0, "", "") ``` Also, gnome sends a nil preedit string in text-input-v3 as well: ``` zwp_text_input_v3#40.preedit_string(nil, 0, 0) zwp_text_input_v3#40.done(514) ```
You are right that kwin does this. Though note that from the documentation: >Values set with this event are double-buffered. >They must be applied and reset to initial on the next zwp_text_input_v3.done event. >The initial value of text is an empty string, and cursor_begin, cursor_end and cursor_hidden are all 0. We sent the done after the あ character, when we send done again, the client should be applying "", 0, 0 anyway. I think this makes it a client bug.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6470
I made a pending patch, then we have options available if I'm talking nonsense or if a released Chrome relies on this behaviour.
@David Thanks for looking into this. > They must be applied and reset to initial on the next zwp_text_input_v3.done event This is true. However, I was not sure when that is applicable, because the following doc from zwp_text_input_v3.done seems somewhat contradictory: > Instruct the application to apply changes to state requested by the preedit_string, commit_string and delete_surrounding_text events So it was my interpretation that if there are no state changes explicitly requested by those events, there are no changes to be applied. I could be interpreting it wrong still, or perhaps there could be some further clarification in the protocol. > if a released Chrome relies on this behaviour Technically chrome does have an "experimental" option to enable text-input-v3 which does rely on this behavior, but it's still not an officially supported feature yet, and probably won't be until the key events are supported. However, users might be running into this until then. So I'm open to it being addressed in either chrome or KDE.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
Any updates on this? It looks like Chromium want to fix it on their end but no progress since. https://issues.chromium.org/issues/40113488#comment128
There is a draft merge request with a patch for this, which is awaiting review. The link is in this bug report.