inputmethod, zwp_virtual_keyboard_v1 and text-input-v3 message loop with certain text-input-v3 implemenation

[wengxt]

Please fill out the following:

• Sway Version:

  • 1.9

• Debug Log:

  • 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.

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.

[wengxt]

Message loop in gedit:

https://gist.github.com/wengxt/22b701add70e1897afea8216077aa62c

[wengxt]

Sway current implemation seems to also a conflict between wl_keyboard.enter & text-input-v3.enter

text-input-v3 focus may not follow wl_keyboard focus in this case as seen in the message trace.

[wengxt]

Specifically, the code here:

sway/sway/input/seat.c

Line 807 in 2686afb

struct wlr_surface *surface = seat->wlr_seat->keyboard_state.focused_surface;

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.