You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run sway -d 2> ~/sway.log from a TTY and upload it to a pastebin, such as gist.github.com.
This will record information about sway's activity. Please try to keep the reproduction as brief as possible and exit sway.
Attach the full file, do not truncate it.
Description:
In fcitx 5 5.1.9, fcitx changes how it handles the zwp_virtual_keyboard_v1, by only create zwp_virtual_keyboard_v1 object when input method is activated. The rational behind this is that, there was once people report bug about virtual keyboard key may be keep pressed, specifically for the modifier keys, and destroy virtual keyboard object itself, seems to clear out all such state that fcitx can't control when keyboard grab shouldn't be placed.
However, we see some infinite message loop triggered by this change in sway, because when zwp_virtual_keyboard_v1 is destroyed, sway will send a wl_keyboard.leave and immediately followed by another wl_keyboard.enter.
They seems to associate the wl_keyboard focus with window focus, and thus, wl_keyboard.leave will trigger a window focus out, and thus send text-input-v3.disable.
While this seems to be a easy fix (only enable / disable after text-input-v3.enter), I still wonder if sway's behavior of wl_keyboard.enter & wl_keyboard.leave on virtual keyboard change is really a desirable behavior since it would trigger window focus change in client.
The text was updated successfully, but these errors were encountered:
virtual keyboard is implemented as a "sway device" thus it may trigger the "synthetic" focus change here.
This somehow may mess up the application that relies on wl_keyboard.enter/leave to handle the window focus change. And it makes text-input-v3 focus and wl_keyboard focus inconsistent.
wengxt
added a commit
to fcitx/fcitx5
that referenced
this issue
May 7, 2024
This reverts commit b2924bd.
While I don't think it's doing anything wrong, but many wlroots
comopsitor does not like this and may make Gtk app choke.
(#1044, #1037, #1039)
swaywm/sway#8143
Please fill out the following:
Sway Version:
Debug Log:
sway -d 2> ~/sway.log
from a TTY and upload it to a pastebin, such as gist.github.com.Description:
In fcitx 5 5.1.9, fcitx changes how it handles the zwp_virtual_keyboard_v1, by only create zwp_virtual_keyboard_v1 object when input method is activated. The rational behind this is that, there was once people report bug about virtual keyboard key may be keep pressed, specifically for the modifier keys, and destroy virtual keyboard object itself, seems to clear out all such state that fcitx can't control when keyboard grab shouldn't be placed.
However, we see some infinite message loop triggered by this change in sway, because when zwp_virtual_keyboard_v1 is destroyed, sway will send a wl_keyboard.leave and immediately followed by another wl_keyboard.enter.
As seen in gtk's text-input-v3 and kovidgoyal/kitty#7396 .
They seems to associate the wl_keyboard focus with window focus, and thus, wl_keyboard.leave will trigger a window focus out, and thus send text-input-v3.disable.
The message loop looks like
sway: wl_keyboard.leave
-> gedit: text-input-v3.disable
-> sway: zwp_input_method_v2.activate
-> fcitx5 create_virtual_keyboard
-> wl_keyboard.leave & wl_keyboard.enter (triggered by virtual keyboard re-creation)
-> gedit: text-input-v3.disable / enable # <<----------- loop starts here.
While this seems to be a easy fix (only enable / disable after text-input-v3.enter), I still wonder if sway's behavior of wl_keyboard.enter & wl_keyboard.leave on virtual keyboard change is really a desirable behavior since it would trigger window focus change in client.
The text was updated successfully, but these errors were encountered: