Summary: | text-input-v3: kwin does not send empty preedit when backspace is pressed after composing one character. | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | orko <orko> |
Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | ilovecreeper372, kde, kdedev, nate, orko |
Priority: | HI | ||
Version: | 6.2.4 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
orko
2024-08-26 16:55:44 UTC
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. |