No interaction (keys/mouse) sometimes

[bczhc]

I'm not sure if there's already an reported issue regarding this anyway I'm filing this now. I'm on niri compositor, with rofi 2.0.0. Sometimes, the launched rofi will go into a strange state where it refuses interactions like arrow keys, mouse clicks/wheels, and even Esc. See the demonstration video:

1.mp4

Have tried many many times to trigger it. I can't tell a probability percentage because seems the bug happens totally randomly.

In the video, I do Mod+V to launch rofi (niri config Mod+V { spawn "bash" "-c" "wldebug rofi -dpi 72 -show | tee -a ~/wllog"; }). And when the bug occurs, wayland message and keyd-monitor all show that the keys are dispatched but rofi doesn't respond. Notably, once I do a bare Ctrl press (and then release), rofi will become normal (the final part of the demo video above) and arrows/clicks/wheels/esc starts working again.

The issue was not present under X11 when I was using i3wm before.

[DaveDavenport]

Never seen/heard of this issue before.
Do you launch rofi on key press or key release?

[bczhc]

I launch it using niri keybind Mod+V and once V is down rofi shows so it's a key press.
It looks like the issue only happens under niri and only when using niri keybind. I tested with Hyprland (also using keybind), or with niri but launched rofi directly from the terminal, for both I couldn't reproduce the issue. Just have no idea how can I debug this issue more.

[bczhc]

Okay. I wrote a script that uses ydotool to demonstrate the bug and with this now it's easy to reproduce it.

rofi-bug.sh

#!/bin/bash

ydotool() {
    sudo /bin/ydotool "$@"
}

ydotool debug > /dev/null

while :; do
    ydotool key 125:1
    ydotool key 47:1
    ydotool key 47:0
    ydotool key 125:0
    sleep 0.1
    ydotool key 1:1
    ydotool key 1:0
    sleep 0.1

    #rofi_present="$(niri msg -j layers | jq '.[] | select(.namespace == "rofi")' | jq -s 'length')"
    
    rofi_present=0
    pgrep --full 'rofi -dmenu' && rofi_present=1

    if [ "$rofi_present" -eq 1 ]; then
        echo 'Bug triggered'
        break
    fi
done

The latest next branch rofi doesn't have this bug. So I'm able to do the bisect. Result shows d256632 is the first commit that fixed the bug.

/mnt/nvme/op/rofi @d256632d bisect ?1 ❯ git bisect fixed        08:47:29
d256632dc9f80da321810ffb8e9bbf7fdcda7ac3 is the first 'fixed' commit
commit d256632dc9f80da321810ffb8e9bbf7fdcda7ac3 (HEAD)
Author: Hanssen0 <hanssen0@hanssen0.com>
Date:   Sun Sep 14 12:38:40 2025 +0800

    feat: support [`text-input-unstable-v3`](https://wayland.app/protocols/text-input-unstable-v3)

    This enables input method support for Rofi under Wayland.

 include/view.h             |  8 ++++
 include/wayland-internal.h |  4 ++
 meson.build                |  1 +
 source/view.c              |  8 ++++
 source/wayland/display.c   | 85 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 106 insertions(+)

However the 'fixed' version of rofi has not been released yet,..

[bczhc]

And this bug will only happen when my IME (fcitx5) is running. I now suppose this is a niri bug because I tested cosmic-comp, sway and Hyprland, even with fcitx5 running the bug won't be triggered.

-- Normal
[02:06:33.044550] {Default Queue}  -> wl_seat#10.get_keyboard(new id wl_keyboard#13)
[02:06:33.057900] {Default Queue} wl_keyboard#13.keymap(1, fd 9, 35572)
[02:06:33.058504] {Default Queue} wl_keyboard#13.repeat_info(25, 600)
[02:06:33.079799] {Default Queue} wl_keyboard#13.enter(78072, wl_surface#3, array[4])
[02:06:33.079807] {Default Queue} wl_keyboard#13.modifiers(78072, 64, 0, 16, 0)
[02:06:33.082355] {Default Queue} wl_keyboard#13.key(78076, 25354336, 125, 0) -- META UP
[02:06:33.082359] {Default Queue} wl_keyboard#13.modifiers(78076, 0, 0, 16, 0)
[02:06:33.280047] {Default Queue} wl_keyboard#13.key(78077, 25354533, 108, 1) -- ArrowDown down
[02:06:33.351970] {Default Queue} wl_keyboard#13.key(78078, 25354605, 108, 0)
[02:06:33.458689] {Default Queue} wl_keyboard#13.key(78079, 25354712, 108, 1)
[02:06:33.540060] {Default Queue} wl_keyboard#13.key(78080, 25354793, 108, 0)
[02:06:33.603933] {Default Queue} wl_keyboard#13.key(78081, 25354857, 15, 1)

-- Bug
[02:06:33.890237] {Default Queue}  -> wl_seat#10.get_keyboard(new id wl_keyboard#13)
[02:06:33.909478] {Default Queue} wl_keyboard#13.keymap(1, fd 9, 35572)
[02:06:33.910107] {Default Queue} wl_keyboard#13.repeat_info(25, 600)
[02:06:33.940968] {Default Queue} wl_keyboard#13.enter(78100, wl_surface#3, array[4])
[02:06:33.940977] {Default Queue} wl_keyboard#13.modifiers(78100, 64, 0, 16, 0) -- Notice here below the "META UP" is lost so rofi thinks the Meta key is always pressed, exhibiting the bug
[02:06:34.141962] {Default Queue} wl_keyboard#13.key(78105, 25355395, 108, 1) -- ArrowDown down
[02:06:34.223063] {Default Queue} wl_keyboard#13.key(78106, 25355476, 108, 0)
[02:06:34.347059] {Default Queue} wl_keyboard#13.key(78107, 25355600, 108, 1)
[02:06:34.420184] {Default Queue} wl_keyboard#13.key(78108, 25355673, 108, 0)
[02:06:34.518160] {Default Queue} wl_keyboard#13.key(78109, 25355771, 108, 1)
[02:06:34.598066] {Default Queue} wl_keyboard#13.key(78110, 25355851, 108, 0)
[02:06:34.718900] {Default Queue} wl_keyboard#13.key(78111, 25355972, 108, 1)
[02:06:34.796115] {Default Queue} wl_keyboard#13.key(78112, 25356049, 108, 0)
[02:06:36.296172] {Default Queue} wl_keyboard#13.modifiers(78121, 4, 0, 16, 0)
[02:06:36.402185] {Default Queue} wl_keyboard#13.key(78122, 25357655, 29, 0)
[02:06:36.402224] {Default Queue} wl_keyboard#13.modifiers(78122, 0, 0, 16, 0)
[02:06:36.595068] {Default Queue} wl_keyboard#13.key(78123, 25357848, 1, 1)

update: niri bug tracked: niri-wm/niri#4520

[DaveDavenport]

Thanks for the thorough testing.

No idea when there will be a release, I'm very low on time,