Shift key locked in when pressed once in Wayland

[rakhusur]

Bug Description

Hi,

I’m experiencing the following bug, which seems similar to #6263 , but occurs under different conditions.

When pressing and releasing the shift key when a slint window is focused, the shift state becomes locked in for the following purposes:
• Turning the scroll wheel scrolls horizontally instead of vertically
• Clicking on a TextInput (or LineEdit or TextEdit) or pressing movement keys when it’s focused causes text to be selected instead of just cursor movement.

Pressing shift again doesn’t help, but focusing a different window does.

It occurs with both the winit and Qt backend as well as in the preview window of the VSCode extension. The issue appears on wayland but not on Xorg.

Reproducible Code (if applicable)

use slint::slint;

slint!{
    export component MainWindow inherits Window {
        TextInput {}
    }
}

fn main() {
    let main_window = MainWindow::new().unwrap();

    main_window.run().unwrap();
}

Environment Details

• Slint Version: 1.9.1
• Platform/OS: Gnome (Wayland), Arch Linux
• Programming Language: Rust
• Backend/Renderer: Qt, winit

Product Impact

No response

[tronical]

I tried to reproduce this under Gnome (Wayland) but I'm not having any luck :-(. @rakhusur could you try installing wev and see if the output there indicates if you're getting a release event?

Similarly, if you could run the slint app that reproduces this on your machine while WAYLAND_DEBUG=1 being set, could you paste the output here that you get when you press and release the shift key?

[rakhusur]

Sorry for the long delay. Here’s the output of wev and WAYLAND_DEBUG:

[14:     wl_keyboard] key: serial: 690; time: 412905; key: 50; state: 1 (pressed)
                      sym: Shift_L      (65505), utf8: ''
[14:     wl_keyboard] modifiers: serial: 1; group: 0
                      depressed: 00000001: Shift 
                      latched: 00000000
                      locked: 00000000
[14:     wl_keyboard] key: serial: 692; time: 413952; key: 50; state: 0 (released)
                      sym: Caps_Lock    (65509), utf8: ''
[14:     wl_keyboard] modifiers: serial: 1; group: 0
                      depressed: 00000000
                      latched: 00000000
                      locked: 00000000

Something strange seems to be going on with Caps_Lock?

[2342484.255] {Default Queue} wl_keyboard#20.key(1026, 617661, 42, 1)
[2342484.288] {Default Queue} wl_keyboard#20.modifiers(1027, 1, 0, 0, 1)
[2343575.101] {Default Queue} wl_keyboard#20.key(1028, 618752, 42, 0)
[2343575.128] {Default Queue} wl_keyboard#20.modifiers(1029, 0, 0, 0, 1)

I found out that the bug is related to the keyboard layout used. A minimal way to reproduce for me is to activate the "German (Neo 2)" layout. (This is an 8-layer layout with additional modifier keys, but the shift keys should be left untouched.)

And now it gets wierd: if both this layout and a more standard, say US, are configured in gnome settings, the order matters. If, in the gnome settings dialog, the US is placed above neo, the bug appears only when
neo is active. If, however, neo is placed above US, it appears even for the US layout.

[tronical]

Thanks for the detailed info, with your mention of the keyboard layout I can reproduce this. I think that this is a bug in the symbol mapping for the keyboard layout, but I think we should work around it.

[tronical]

Looks like our logic for using the key press and release events to determine the modifier state in Slint is incompatible with this particular buggy keyboard layout. The way we should work around it is to use to the modifier state reported by the windowing system to determine the modifier state in Slint. This applies to the Qt as well as the Winit backend, and probably the linuxkms backend, too.

We should perhaps work around it by mapping the modifier state changes reported by the windowing system to synthetic key press/release events in Slint for the modifier keys. The other option would be to introduce a modifier specific event in the Slint window event API, but that would probably break existing custom platform backends.

[rakhusur]

Narrowed it down a little bit: the culprit is the shift(both_capslock) option that is part of neo. I can reproduce the issue with a standard layout by activating the option "Both shift keys toggle caps" in gnome optimization tool. This also leads to the CapsLock release messages in wev (although doing the same in X11 also produces CapsLock release events in xev).

[tronical]

Interesting! So this is more widespread and not entirely specific to this layout. Thanks for digging :)