Keyboard not being recaptured after passing special keys with --special-passthrough

[SafwanLjd]

This issue is a....

[x] Bug
[ ] Other kind of issue (Please describe in detail)

Current Behavior

slightly after using one of the "special keys" (i.e. the volume keys), you get the ability to pass any key, if you use the shortcut keys to launch another program that requests the focus, like a terminal, you'll be able to run commands, i.e. pkill i3lock

Expected Behavior

This shouldn't happen

Reproduction Instructions

Here is a demonstration where I'm using sxhkd to bind "Super + Enter" to launch Alacritty

Environment

Output of i3lock --version:
i3lock: version aur-ac6b471 (2022-01-25)

Where'd you get i3lock-color from?

[x] AUR package (i3lock-color-git)
[ ] Built from source yourself
[ ] Other (Please describe in detail)

[JezerM]

Certainly, I was expecting something related to --special-passtrough, but not like this. It's weird that i3lock doesn't regain its keyboard control... I'll have to check it.

[JezerM]

Does this happens only with volume keys? Or brightness and media keys too?

[SafwanLjd]

It happens with all the "special" keys, I just used the volume keys as an example

[JezerM]

Also, does this only happens with sxhkd? Have you tested other Window Managers/Desktop Environments where this issue occurs?

[SafwanLjd]

I haven't, since that's the only environment I use... but sxhkd is the most popular stand-alone hotkey daemon, so it'd be a big deal even if it's just that

[JezerM]

I can confirm this happens with sxhkd and dwm.

[Raymo111]

Oh dear. @SafwanLjd thanks for reporting this, @JezerM please fix this as soon as you can, I'm gonna wait until that happens to release a new version.

[JezerM]

For now, this feature had to be reverted.

[Raymo111]

Feat reverted due to the same vuln being present on KDE (and this probably everywhere the flag is used).