[BUG] Rofi window mode does not seem to work anymore in Hyprland

[LorenzoBettini]

Rofi version (rofi -v or git commit in case of build issue)

Version: 1.7.5+wayland1-48-gd06095b5 (makepkg)

Configuration

https://gist.github.com/LorenzoBettini/155b336f0a4ce302df771d7b542cebd1

Theme

https://gist.github.com/LorenzoBettini/4a3dff4c44060e9b08951ee205e050a0

Timing report

No response

Launch command

rofi -show window

Step to reproduce

• rofi -show window
• the list of windows appears
• select one but nothing happens

Expected behavior

Once a window is selected it should be focused, and in case it's in another workspace, the workspace should also be switched

Actual behavior

It used to work before but now nothing happens.

Additional information

Maybe it's related to this:

wmctrl -l
Cannot get client list properties. 
(_NET_CLIENT_LIST or _WIN_CLIENT_LIST)

Using wayland display server protocol

• [X] Yes, I use rofi with wayland support

I've checked if the issue exists in the latest stable release

• [X] Yes, I have checked the problem exists in the latest stable version

[LorenzoBettini]

Hyprland version: hyprland 0.35.0-2 in Arch Linux

[lbonn]

Thanks, I have just tried (on Hyprland latest git revision) and it looks indeed broken.

This should be filed in Hyprland issues IMO: activate in wlr-foreign-toplevel-management stopped working between 0.34 and 0.35?

[LorenzoBettini]

@lbonn do you plan to report it yourself? Maybe you have more knowledge of the involved low-level mechanisms. I could only guess about wmctrl, but maybe that's not even related to the problem?

[lbonn]

@LorenzoBettini ok, done. I don't use Hyprland myself, if they are asking for more version details or testing, maybe you can assist at https://github.com/hyprwm/Hyprland/issues/4829 :)

[LorenzoBettini]

@lbonn thanks. They've already answered in that issue but I seem to understand they mention a new procedure that must be implemented in the window mode of rofi, right?

[lbonn]

Yes, rofi is taking keyboard focus and we activate the target window before releasing the focus. It's not something that's really specified as far as I know but I also don't see why it should be such a problem in practice (would have to look into it).

Releasing the keyboard interactivity before activating the window would complicate things a bit.

likely https://github.com/hyprwm/Hyprland/commit/17339e0ae9ad01dcfdede76e8dfaf516a8cbb924

you need to:

unmap your ls then issue an activate then do whatever else and exit

if you issue an activate while you still have a keyboard-exclusive LS open, it will be ignored.

@alebastr any thoughts on this?

[LorenzoBettini]

I'm afraid I can't help from the implementation point of view, but I can test possible fixes in case you come up with something.

[alebastr]

This seems surprisingly easy to implement: XCB window mode calls rofi_view_hide before activating the selection. And since XCB already behaves that way, it's not unreasonable to adjust the Wayland code.

We could add the missing implementation for wayland_rofi_view_hide and do the same in wayland-window.

[alebastr]

https://github.com/lbonn/rofi/pull/118

I haven't tested on Hyprland, it may require full wl_display_roundtrip in display_surface_unmap to make the compositor aware that the surface is unmapped.

[LorenzoBettini]

I'm afraid we should re-open this, since the problem shows up again in Hyprland 0.40. I've already raised an issue on Hyprland because it also happens in other programs changing the window: https://github.com/hyprwm/Hyprland/issues/6236

[lbonn]

@LorenzoBettini if it's another regression on hyprland side, I see no need to track it here.

In case rofi-wayland need some changes to work on hyprland again (does not seem to be the case so far?), I would prefer opening another separate issue as this particular one has been resolved already and it quickly gets confusing to talk about two similar bugs with different root causes in the same discussion thread.