Double input with fcitx5 on chrome dev under some cases

[BRS5672023]

System Information

• niri version: niri 0.1.8 (unknown commit)

• Distro: Arch Linux

• GPU: Radeon 780M Graphics

• CPU: AMD Ryzen 7 8845H

Chrome dev which utilizes text-input-v3 has the issue of letters get doubly input for certain input boxes, even when no ime is in use (but no issues when the process of fcitx5 is being killed), for example, the Filters input box (where I typed just one "d" letter)

As suggested in the comment Ozone-wayland: support text_input_v3 protocol, the related log output in terminal is

[1979825.472] [email protected](22, "zwp_text_input_manager_v3", 1)
[1979825.474]  -> [email protected](22, "zwp_text_input_manager_v3", 1, new id [unknown]@18)
[1979834.764] {Default Queue} wl_registry#2.global(22, "zwp_text_input_manager_v3", 1)
[1979938.191]  -> [email protected]_text_input(new id zwp_text_input_v3@37, wl_seat@22)
[1980096.161] [email protected](wl_surface@28)
[1981833.399]  -> [email protected]()
[1981833.402]  -> [email protected]()
[1981833.403]  -> [email protected]()
[1981833.404]  -> [email protected]()
[1981834.973]  -> [email protected]()
[1981834.979]  -> [email protected]()
[1981834.981]  -> [email protected]()
[1981834.982]  -> [email protected]()
[1981835.155]  -> [email protected]()
[1981835.166]  -> [email protected]()
[1981835.168]  -> [email protected]()
[1981835.169]  -> [email protected]()
[1981836.715]  -> [email protected]_text_input(new id zwp_text_input_v3@47, wl_seat@22)
[1981837.398] [email protected](wl_surface@28)
[1981837.399] [email protected](wl_surface@28)
[1982015.270]  -> [email protected]()
[1982015.275]  -> [email protected]()
[1982190.953]  -> [email protected]()
[1982190.957]  -> [email protected]()
[1982190.960]  -> [email protected]()
[1983418.747]  -> [email protected]()
[1983418.753]  -> [email protected]()
[1983418.755]  -> [email protected]()
[1983418.756]  -> [email protected]()
[1983418.761]  -> [email protected]()
[1983418.762]  -> [email protected]()
[1983419.080] [email protected](wl_surface@28)
[1984897.447]  -> [email protected]()
[1984897.448]  -> [email protected]()
[1984897.451]  -> [email protected]()
[1984897.452]  -> [email protected]()
[1984897.453] [email protected](wl_surface@28)
[1986241.720]  -> [email protected]()
[1986241.739]  -> [email protected]()
[1986241.741]  -> [email protected]()
[1986241.742]  -> [email protected]()
[1986241.744]  -> [email protected]()
[1986241.745]  -> [email protected]()
[1986252.780] [email protected](wl_surface@28)
[1986256.543]  -> [email protected]()
[1986256.546]  -> [email protected]()
[1986256.548]  -> [email protected]()
[1986281.178]  -> [email protected]()

And it seems there are indeed two key press events when a double input is triggered

[3538254.262] [email protected](40066, 1469355, 32, 1)
[3538254.655] [email protected](40067, 1469355, 32, 1)
[3538268.279] [email protected](40068, 1469355, 32, 0)
[3538334.655] {Default Queue} wl_keyboard#26.keymap(1, fd 296, 64753)
[3538336.809] [email protected](1, fd 296, 64754)
[3538338.062] [email protected](40070, 1469436, 32, 0)

While I don't have any other application that utilize text-input-v3 I can test with, and most input boxes in chrome are working fine.

[YaLTeR]

Uhh, honestly no clue about the text-input and IME stuff. Though, people have been using it fine with other clients.

@kchibisov do you perhaps have any idea what could be happening here?

[kchibisov]

it's a virtual keyboard that acting weirdly, I'd say, but it just forwards whatever you have in pressed.

Maybe the fact that chrome does a lot of enable/disable somehow confuses fcitx, since niri itself will send the key event either to fcitx or to the application directly, it can not send it to both sources?

What I'd suggest is to debug fcitx and not chrome here, and try to figure out the source of the double input.

I use text-input-v3 with fcitx5 daily with all the apps I have and I've never seen such a thing, so it could be an edge case in fcitx5 or maybe some edge case in niri (which I doubt).

[BRS5672023]

Maybe the fact that chrome does a lot of enable/disable somehow confuses fcitx, since niri itself will send the key event either to fcitx or to the application directly, it can not send it to both sources?

I found something maybe related, the Filter input box cannot actually get input from ime (where it does not allow me to switch to any other input rather than english), and one another place where I can trigger this issue consistently is the danmuku input box on bilibili when it is in fullscreen mode, where it also does not allow me to switch ime..

[kchibisov]

Well, I'd suggest to debug either niri directly or fcitx, since chrome just receives things, you can also compare to e.g. firefox, it also uses all of that.

[BRS5672023]

Well, I'd suggest to debug either niri directly or fcitx, since chrome just receives things, you can also compare to e.g. firefox, it also uses all of that.

It is totally fine with firefox though (ime can be invoked correctly under all cases).. I'd assume it is similar when launching chrome with the flag --gtk-version=4 and the environment variable GTK_IM_MODULE=fcitx is set, but the candidate box cannot be shown on the latter case, which makes ime unusable though free of the double input issues.

[kchibisov]

I mean, firefox is still gtk3 IIRC, also use GTK_IM_MODULE=wayland for firefox, so it's also text-input-v3, that's what I use at least, since I don't use any fcitx specific input module in anything other than QT, because QT 5 doesn't support text-input-v3.

[BRS5672023]

I mean, firefox is still gtk3 IIRC, also use GTK_IM_MODULE=wayland for firefox, so it's also text-input-v3, that's what I use at least, since I don't use any fcitx specific input module in anything other than QT, because QT 5 doesn't support text-input-v3.

I'm launching firefox without the environment GTK_IM_MODULE set as suggested by fcitx5 itself , but I cannot get fcitx5 working on chrome under this case until latest versions of chrome dev involving text-input-v3 patches (and different flags --enable-wayland-ime --wayland-text-input-version=3 rather than --gtk-version=4).

According to the wiki

There are a few different options in terms of setting the value of GTK_IM_MODULE. When it is unset, the Gtk built-in Wayland im module will be used for Gtk3 and Gtk4. While you can also enforce it by doing GTK_IM_MODULE=wayland, remember it will be also picked up by Gtk2.

It is maybe unnecessary to set GTK_IM_MODULE=wayland. I don't know if it is a issue specific to chrome or compositor related..

[kchibisov]

GTK_IM_MODULE=wayland is likely a thing of the past already, but you can check that firefox uses v3 the same way you did with chrome. I could say that it uses v3 as well.

[lambdaclan]

With the recent promotion of Chrome 129 to the stable channel which finally brings text-input-v3 support via a flag I got a chance to test fcitx5. Unfortunately, I can confirm this issue does persist. Actually, I have discovered why it happens only sometimes. It comes down to how many instances are running.

If you are running a single instance (window) of Chrome (or any Chromium based browser version >=129.0.6643.2) then you will never notice the issue. Fcitx5 works as expected, just as good as Firefox. Now if you open a new window every single key input is doubled a → aa, but there is more... If you open yet another window then yeap, every single key input is tripled a→aaa, and it goes from there.

The reason I discovered this is because I use a lot of webapps (standalone PWAs == instance windows) so it quickly became apparent that the number of windows open has something to do with the extra unnecessary input.

To replicate the issue you can install latest Chrome Canary or any other Chromium based browser (you need to have fctix5 running). For my tests I was using Brave from Flathub:

Version 1.70.117 Chromium: 129.0.6668.59 (Official Build) unknown (64-bit)

Simply launch Brave with:

flatpak run com.brave.Browser --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime --wayland-text-input-version=3

First window should be working without any issues, for example just typing in the address bar using various inputs. Now simply open another window and try the same test, you should be getting doubled output for each key press. Opening another window will triple the output and so forth.

Keep in mind that opening an extra window after the first also breaks the input in the first window. For some reason fcitx5 also forgets the input methods (trying to switch only shows the top one in the list).

I can confirm that Firefox (flatpak) without any special flags works with fcitx5 under niri with zero issues. Both Brave and Firefox work as expected under Gnome Wayland.

I am aware that niri is still young but this issue in combination with #454 are real pain points which make using niri almost unbearable which is a real shame since I love using niri. Now, I am not a Rust programmer (still learning) but If there is anything I can do to help debug and resolve these problems with fcitx5 please let me know. I will be happy to help out as much as I can!

Let me know if more info is required.

Thank you all for your work on niri!

[BRS5672023]

If you are running a single instance (window) of Chrome (or any Chromium based browser version >=129.0.6643.2) then you will never notice the issue. Fcitx5 works as expected, just as good as Firefox. Now if you open a new window every single key input is doubled a → aa, but there is more... If you open yet another window then yeap, every single key input is tripled a→aaa, and it goes from there.

Actually it is an another case where a double (multiple) input is triggered.. With chromium 129 now using text-input-v3 there is no double input when entering text in the filter box I mentioned, while on google-chrome-dev this issue still persists, and in both cases the fullscreen danmaku input boxes on bilibili will trigger the double input issue (I do not have any pwa apps or electron apps running). I didn't see the same issue on hyprland, though (with the same chromium flags).. By the way, if multiple chromium instances opened on hyprland, I cannot get any input with fcitx5 and text-input-v3..

[YaLTeR]

Could you please try Chrome/Brave under sway with fcitx5 and make sure they are running on Wayland and not Xwayland, to check if the issue is niri specific?

[lambdaclan]

Actually it is an another case where a double (multiple) input is triggered.. With chromium 129 now using text-input-v3 there is no double input when entering text in the filter box I mentioned, while on google-chrome-dev this issue still persists, and in both cases the fullscreen danmaku input boxes on bilibili will trigger the double input issue (I do not have any pwa apps or electron apps running). I didn't see the same issue on hyprland, though (with the same chromium flags).. By the way, if multiple chromium instances opened on hyprland, I cannot get any input with fcitx5 and text-input-v3..

The plot thickens… I guess we might be dealing with completely different issues then.

Could you please try Chrome/Brave under sway with fcitx5 and make sure they are running on Wayland and not Xwayland, to check if the issue is niri specific?

I setup a Sway VM using Ubuntu Sway Remix and can confirm that everything is working as expected.

To reproduce my setup just do the following:

1. Setup Flathub

sudo apt install -y flatpak
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

2. Setup Fcitx5 (I used mozc as an extra input, but anything will do)

sudo apt install -y fcitx5-mozc fcitx5-config-qt fcitx5-frontend-all

3. Add mozc as an extra input to Fcitx5 (optional)

fcitx5-configtool

4. Reboot

5. Install Brave from Flathub

flatpak install flathub com.brave.Browser

6. Launch Fcitx5

fctix5 --replace

7. Launch Brave and test as described in my previous post

flatpak run com.brave.Browser --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime --wayland-text-input-version=3

Another example showing multiple inputs working as expected (English, mozc)

[lambdaclan]

I didn't see the same issue on hyprland, though (with the same chromium flags).. By the way, if multiple chromium instances opened on hyprland, I cannot get any input with fcitx5 and text-input-v3..

Just performed the same tests as above on latest hyrpland (git) and it also works as expected. Multiple Brave intances on hyprland worked just fine, maybe it is worth testing once more since Brave with Chromium 129 was just recently released.

[merrkry]

Reproduced on Niri 0.1.9 with Chromium 130.0.6723.91

[oluceps]

Reproduced on Niri 0.1.9 with Chromium 130.0.6723.91

+1 and with Chromium 131.0.6778.13

[CoelacanthusHex]

Could you please try Chrome/Brave under sway with fcitx5 and make sure they are running on Wayland and not Xwayland, to check if the issue is niri specific?

FYI, according to some discussion in Arch Linux CN group, at least in KWin and wayfire, there is no issue.

[YaLTeR]

When running on Wayland and not Xwayland?

[merrkry]

When running on Wayland and not Xwayland?

I tried to run Chrome with xwayland-run without the wayland flags. This doesn't happen. I believe this issue is very much related to text-input-v3.

[Bot-wxt1221]

The same problem happened for me on every chromium-based software like edge and chrome.

[CnTeng]

Maybe, this is the reason. https://issues.chromium.org/issues/40113488#comment127