[text-input-v3] No response with `done` events to `commit` requests if there are no `preedit_text`/`commit_text` events to send

[OnePatchGuy]

Hello! Forwarding the issue here from YaLTeR/niri#3067.

For example, if a client application sends a sequence of requests zwp_text_input_v3::set_cursor_rectangle+zwp_text_input_v3::commit, Niri doesn't respond with a zwp_text_input_v3::done event until it needs to send a zwp_text_input_v3::preedit_text/commit_text event. According to the protocol specification, it makes impossible for client applications to send another zwp_text_input_v3::set_cursor_rectangle+zwp_text_input_v3::done if the caret position changes due to:

When the client receives a done event with a serial different than the number of past commit requests, it must proceed with evaluating and applying the changes as normal, except it should not change the current state of the zwp_text_input_v3 object. All pending state requests (set_surrounding_text, set_content_type and set_cursor_rectangle) on the zwp_text_input_v3 object should be sent and committed after receiving a zwp_text_input_v3.done event with a matching serial.

(it's a quote from the specification of zwp_text_input_v3::done)

That is, after a pair of zwp_text_input_v3::set_cursor_rectangle+zwp_text_input_v3::commit, clients mustn't send another one until a done is received. And this rule isn't restricted to set_cursor_rectangle only.

In the other words, the behavior should be adjusted so as to zwp_text_input_v3::done events are sent as soon as the Wayland compositor processes zwp_text_input_v3::commit requests from clients regardless of whether there are zwp_text_input_v3::preedit_text/commit_text events to send.

Steps to reproduce

1. Install a 2025.3 release of any JetBrains IDE (it's important to use 2025.3 or higher, because earlier releases don't provide text-input-v3 support), e.g. the free IntelliJ IDEA Community Edition (https://www.jetbrains.com/idea/download/?section=linux).
2. Press Ctrl+Shift+A -> start typing "Edit Custom VM Options..." and choose this option when it appears.
3. In the opened dialog add the following line: -Dawt.toolkit.name=WLToolkit.
4. Close the IDE.
5. Launch it again from the terminal like this: WAYLAND_DEBUG=1 idea | grep -E 'zwp_text_input_v3'.
6. Open a file in the IDE and start typing something but not using the input method - typing just regular latin characters is enough.
7. After 1-2 typed characters you'll notice that the IDE stops sending set_cursor_rectangle.

System Information

• niri version: 25.11

• Distro: Arch Linux 6.17.9
• fcitx5: 5.1.16

• GPU: unknown (unlikely matters)

• CPU: unknown (unlikely matters)

[YaLTeR]

cc @kchibisov

[kchibisov]

In the other words, the behavior should be adjusted so as to zwp_text_input_v3::done events are sent as soon as the Wayland compositor processes zwp_text_input_v3::commit requests from clients regardless of whether there are zwp_text_input_v3::preedit_text/commit_text events to send.

There's no such logic in place. It's all deligated to input_method_v2, since commit/done is synced with it. You can post WAYLAND_DEBUG=server log, but it can be an issue with fcitx5?

Also, there could be an issue with commits/serials, hard to answer without any log, but in code, we have no such filterings, however the done is send back to client, once we receive the Commit from the input_method_v2.

[OnePatchGuy]

@kchibisov, just as a proof of my words, you can take a look at the video in the neighboring ticket #1884. From 0:12 to 0:14 in the logs you can notice that the client didn't get a done event after it sent set_cursor_rectangle + commit. The only reason the client gets it later is that the user starts typing using the IM and preedit_text/commit_text events appear.

I understand you need logs of interactions between the compositor and fcitx, but I can't provide them bcs I don't have a corresponding environment set up.

However, if you do, I believe it should be easy to reproduce the problem using the steps provided in the description. Moreover, it should be visible if you run just any Wayland text app (supporting the protocol ofc) with WAYLAND_DEBUG=1 and play with the caret position.

Or if the original affected user shows up here, they may help.

[OnePatchGuy]

but it can be an issue with fcitx5?

At least I can say for sure there's no such a problem with KWin 5.27.11 and fcitx5 5.1.7 (under Kubuntu 24.04). So it's either a recent fcitx5 regression, or KWin takes extra care of this case on its own.

[kchibisov]

, or KWin takes extra care of this case on its own.

That what could be here. I use fcitx myself, so I'll look into it, I'm just saying that we mostly just forward things back and forth, so it's likely IME.

[feng-yifan]

I meet a very samlier situation, in edge browser, you can only use fcitx5 in main window, in this create workspace window, you cannot use fcitx5

@kchibisov

[kchibisov]

@feng-yifan popups on niri requires latest git commit to work.

[kchibisov]

I don't see anything in the spec that the done is required, and I don't see why would it be sent in the first place when nothing got applied. The fcitx doesn't send anything and I'd assume that there's no issue. Also, done is kind of synced with input_method_v2, so it's not clear what should be done here.

cc @dcz-self do you have thoughts about that? From my understanding not sending done to commit without any state change sounds fine to me? And if anything, it should be handled on the IME side and not in the compositor, since I'm not sure compositor can figure things out here.

[kchibisov]

I'd also note that just committing set_cursor_rectangle is also not enough, unless you actually have IME input in e.g. Japanese going on in fcitx. You'll get done once you receive the preedit/commit/etc from the compositor.

I've looked into sway and it also sends done if and only if there's a Commit from the input_method directly.

[dcz-self]

Thanks for pinging me. When drafting the protocol, the intention was that "done" gets sent whenever the input method needs to send it, not in reply to "commit". The client must reply to every (most?) "done" events with a "commit", so replying with another "done" would cause an infinite loop.

All pending state requests (set_surrounding_text, set_content_type and set_cursor_rectangle) on the zwp_text_input_v3 object should be sent and committed after receiving a zwp_text_input_v3.done event with a matching serial.

This sentence is unfortunate and for the life of me, I don't understand it. And I'm probably the one who wrote it, so I'm sorry and I'll try to fix it.

If it's any help, it says "should", not "must.

[kchibisov]

Yeah, I think what we're doing is fine, and we should just obey what input_method is telling us, without inserting arbitrary done events.

Now, if you integrate e.g. input method not via input_method_v2, but via dbus(which kwin might do), kwin should send done events, but smithay just forwards things from text_input to input_method, and it must be synced on input_method side as well, which makes smithay not being able to send done's events on its own reliably.

[dcz-self]

Fix filed: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/479
Please comment if it needs to be improved.

[OnePatchGuy]

@kchibisov @dcz-self, hi! I'm a bit lost in your conversation (because there are both text-input-v3 and input-method-v2 being discussed and sometimes I don't really understand which one is being discussed), so my apologies if some of my questions/comments below are irrelevant.

The main question: what's the proposed solution for text-input-v3 clients? When designing the implementation on our side, the least thing we wanted to cause is data races between the client and the compositor, so we obeyed this part:

All pending state requests (set_surrounding_text, set_content_type and set_cursor_rectangle) on the zwp_text_input_v3 object should be sent and committed after receiving a zwp_text_input_v3.done event with a matching serial.

as if it used "must" instead of "should", because the specification doesn't guarantee any correctness if this rule isn't followed by clients.

I don't see anything in the spec that the done is required, and I don't see why would it be sent in the first place when nothing got applied.

I agree that text-input-v3 doesn't require that explicitly, but it kind of becomes an obvious conclusion when taking into account the reasoning above. (BTW let me know if you don't get my position, I may have explained it not good enough and will be glad to elaborate it more in this case)

I'd also note that just committing set_cursor_rectangle is also not enough, unless you actually have IME input in e.g. Japanese going on in fcitx

If it's still about text-input-v3 , than "is also not enough" for what? My goal is to make sure the compositor is aware of current position of the caret (instead of its some outdated position) before it shows an IM popup so the user won't notice positioning bugs. And from the client application perspective, set_cursor_rectangle + commit is the only way to do so, isn't it?

I've looked into sway and it also sends done if and only if there's a Commit from the input_method directly.

In addition to already mentioned KWin, Mutter is also an example of implementation that always responds to client's commit requests.

smithay just forwards things from text_input to input_method, and it must be synced on input_method side as well, which makes smithay not being able to send done's events on its own reliably.

Good point, from that point a view I'd agree this is rather a fcitx issue.

Fix filed: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/479 Please comment if it needs to be improved.

Honestly I don't understand what's getting changed in the semantics with this patch, could you please elaborate what you wanted to achieve?