[BUG]: Using typing-booster causes shift to constantly register as pressed, causing issues in most apps

[axtloss]

Describe the bug When using typing-booster, after some time apps seem to register the shift key being pressed, causing things like switching tabs in firefox to not work anymore since pressing Shift and selecting a tab causes tabs to be selected.

To Reproduce Steps to reproduce the behavior:

1. Enable typing booster
2. Open Firefox (some electron apps also seem to be affected)
3. Type something with typing-booster enabled, seems to happen most when typing unicode characters
4. Click on a different tab
5. Tabs get selected instead of switching to clicked tab

Expected behavior Shift does not register as constantly pressed down

Screenshots or videos If applicable, add screenshots or videos to help explain your problem.

ibus-typing-booster version? 2.25.3

ibus version? 1.5.28

Distribution and version? Void Linux

Desktop and version? Gnome 45.5

Xorg or Wayland? Wayland

Additional context I was also able to reproduce this issue on fedora silverblue 39

[mike-fabian]

I can reproduce this.

Workaround: Press and release Shift key again (Just the shift key).

Investitating the cause ...

[mike-fabian]

I think I know the reason. When a key press event is handled by ibus-typing-booster, i.e. not passed through to the application, I try to also notpass the release event of the same key to the application. Because a release event for a key where the corresponding press event is missing confuses some applications.

But I have a bug there, I use a variable self._process_key_event_press_key_handled to remember whether press key event was handled. And if there are two press events in a row followed by two release events in a row then there is a bug. Like in this example:

• Press Shift: self._process_key_event_press_key_handled is set to False because a press of Shift is always passed through.
• Press a, which gives a A now because of the Shift. If this press event is handled, self._process_key_event_press_key_handled is set to True, else to False.
• Release a: if the press of a has been handled by ibus-typing-booster, self._process_key_event_press_key_handled is True and the release of a is not passed through.
• Release Shift: if the press of a had been handled, self._process_key_event_press_key_handled is still True and the release of the Shift is not passed through, which is a mistake because the press of the Shift was passed through.

This bug in ibus-typing-booster did not cause a problem in Gnome Wayland on Fedora 38 (works in Gnome Xorg on Fedora 38 as well):

mfabian@fedora:~
$ cat /etc/fedora-release 
Fedora release 38 (Thirty Eight)
mfabian@fedora:~
$ rpm -q firefox mutter gnome-shell
firefox-124.0.1-2.fc38.x86_64
mutter-44.9-1.fc38.x86_64
gnome-shell-44.10-1.fc38.x86_64
mfabian@fedora:~
$ 

but it causes the problem reported here in Gnome Wayland on Fedora 39 (only Wayland, works in Gnome Xorg on Fedora 39):

mfabian@fedora:~
$ cat /etc/fedora-release 
Fedora release 39 (Thirty Nine)
mfabian@fedora:~
$ rpm -q firefox mutter gnome-shell
firefox-124.0.1-2.fc39.x86_64
mutter-45.5-1.fc39.x86_64
gnome-shell-45.5-1.fc39.x86_64
mfabian@fedora:~
$ 

As the firefox versions are the same in Fedora 38 and Fedora 39, I guess something has changed in Gnome Wayland, maybe in mutter.

But it is clearly a bug in ibus-typing-booster, if the press of the Shift was passed through, the release of the Shift should be passed through as well.