https://bugs.kde.org/show_bug.cgi?id=506095
--- Comment #22 from ShwStone <[email protected]> --- (In reply to Weng Xuetian from comment #20) > Hi, fcitx dev here. > > No, such issue can only be triggered by kwin. > > Here's the things: > 1. while there's on/off from user point of view, it's always "on" in the > sense whether the key event flows to input method. > 2. The behavior, as shown in video, seems to be kwin send > zwp_input_method.activate() to fcitx and fcitx placed a keyboard grab. > > While this should be managed together with the keyboard focus, it seems (at > least from the video, since I didn't reproduce it, maybe it requires certain > app?) that kwin fails send deactivate input method when xwayland window get > focused. > > I think the reporter probably want to open a terminal and run fcitx5 with > WAYLAND_DEBUG=1 fcitx5 and focus on the zwp_input_method , so we could see > the interaction between kwin & fcitx & window focus change. > > 1. quit/kill all fcitx5 process > 2. Run `WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method` in a terminal, > keep it visible while recording > 3. Select Fcitx5 Wayland launcher (instead of fcitx5) in systemsettings, so > it can use the fcitx5 started by (2) instead of starting a new one > 4. Try to reproduce the issue your describe. > > When you focus into a non wayland app, if it's normal, you should see: > > ``` > [ 681741.584] {Default Queue} > zwp_input_method_v1#14.deactivate(zwp_input_method_context_v1#4278190081) > ``` Hello, I have finished the recording as requested. The video is attached to this message. Here are the steps I followed and my key observations: **Setup:** 1. In System Settings, I first set the virtual keyboard to "None" to ensure no IM was running. 2. I ran `killall fcitx5` to terminate any lingering processes. 3. I started fcitx5 in a terminal with the debug command: `WAYLAND_DEBUG=1 fcitx5 2>&1 | grep zwp_input_method`. 4. I then went back to System Settings and set the virtual keyboard to "Fcitx 5 (Wayland launcher)". **Reproduction Steps & Observations:** 1. I opened a Konsole window (a native Wayland app). Typing in Chinese worked as expected, and I could see the `zwp_input_method` logs appearing in the debug terminal. 2. I opened an `xterm` window (an Xwayland app). I was able to type in Chinese correctly. **Importantly, during this initial interaction, no new logs related to `zwp_input_method` were generated.** This seems to be the correct behavior, as it's likely using a different protocol for Xwayland. 3. I switched focus back to the Konsole window. Input continued to work correctly, and the Wayland logs were generated as expected. 4. I then switched focus back to the `xterm` window. **At this point, the bug occurred.** I was unable to input any characters into `xterm`. The fcitx5 candidate window appeared incorrectly in the top-left corner of the screen. 5. Most critically, while trying to type in the broken `xterm` window, **`zwp_input_method` logs started appearing in the debug terminal.** This seems to confirm that the Wayland input method protocol is being incorrectly activated for an Xwayland window, causing the input to be intercepted. **Additional Finding:** I also discovered a very specific condition to trigger this bug: the input failure in `xterm` only seems to happen **after the `xterm` window loses and regains visibility** (e.g., it is covered by a larger window and then re-exposed). If I keep the `xterm` window on top of all other windows, the bug does not seem to occur. This might suggest an issue with how window state changes (like occlusion) are handled. I am not an expert, so I hope the logs are clear enough in the video. If needed, I can easily reproduce this again and save the full log output to a file and upload it. Thank you for your help. -- You are receiving this mail because: You are watching all bug changes.
