wlr-layer-shell (bemenu, wmenu) not grabbing focus in multi-output configuration when bar mode is `hide`

[gustafla]

Sway Version:

{
  "human_readable": "1.10.1",
  "variant": "sway",
  "major": 1,
  "minor": 10,
  "patch": 1,
  "loaded_config_file_name": "\/home\/gustafla\/.config\/sway\/config"
}

bemenu v0.6.23

wmenu 0.1.9

Debug Log:
https://gist.github.com/gustafla/ad660e6010ef3f33caa17c4e09397378

If you see the following in the log, it's from me hovering the mouse to the unresponsive bemenu and closing it with esc without choosing a program to launch:

[
  {
    "success": false,
    "parse_error": true,
    "error": "Invalid exec command (expected at least 1 argument, got 0)"
  }
]

In other words the above is an expected error.

Configuration File:
https://github.com/gustafla/dotfiles/blob/f47e55386c66609882b4870ea2d51a7cb43337ee/.config/sway/config

Description:

When my outputs are configured as shown below, wmenu and bemenu launched via a keyboard binding aren't getting focused and won't take any keyboard input on one of the monitors (usually the lower left monitor). This may be related to #8560 or not. The menu starts to respond after moving the mouse over it, and keeps responding even after hovering back out of it.

The problem also does not occur when:

• Running bemenu-run from a terminal, only from a bindsym exec
• One of the three displays is disabled (running in dual monitor configuration)

I tried both Vulkan and GLES2 renderers, both have the same issue. I also tried sway version 1.10.0, it had the same issue.

get_outputs: https://gist.github.com/gustafla/06d3455f32b86e733e1dbf5cd3053b97

[gustafla]

It's also not dependent on adaptive_sync nor the refresh rate. I tested with all monitors adaptive_sync disabled and refresh rate set to default 60 Hz, not mismatched 240, 165, and 144 as I usually would have.

[gustafla]

This also reproduces on my laptop with a completely different set of displays
https://gist.github.com/gustafla/d9d379176f24bd9a94ae4f9f8c9dff8b

[Dryparn]

I get the same problem with all menus I have tested. Bemenu, wofi, rofi, dmenu and so on in a 3 and 4 monitor setup.
It worked perfectly before but I can't remember when it started misbehaving. It's at least a couple of months ago.
In hyprland everything works fine with all of the menus on the same versions.

[Dryparn]

I downgraded my way down the sway versions in Arch and now it seems to work again.
Package versions went from:
Sway: 1:1.10.1-2 -> 1:1.9-5
wlroots: 0.18.2-2 -> 0.17.4-3

[Dryparn]

I get the same problem on the newly released versions.
Sway: 1:1.11.1
wlroots: 0.19.0-1

[Dryparn]

I think i found it.
If i comment "mode hide" out in the sway-bar config it starts behaving ok again.

I guess the hiding interrupts the launcher bar focusing on large monitors because it only happens on my two big 3840x2160 monitors.
The two 1920x1200 monitors are unaffected by the problem.
This problem doesn't exist in sway in 1.9. with wlroots 0.17.4.

EDIT:
When i set my 3840x2160 screens to 1920x1080 the problem is still there so it's probably not affected by screen resolution.
The screens are configured like:

output $montop pos 1920 0 res 3840x2160
output $monleft pos 0 2640 res 1920x1200
output $monmid pos 1920 2160 res 3840x2160
output $monright pos 5760 2640 res 1920x1200

[gustafla]

Thanks for figuring that out! This might be relatively simple to fix with all this narrowing down you've done.

[chr5tphr]

I also encounter the issue in my setup whenever I have two 3840x2160 screens connected in sway 1.11 with wlroots 0.19.0-1.
The issue also disappears for me when I disable hide in the swaybar config.
I also noticed that wofi seems to always be properly focused in hide-mode when the swaybar is hidden during launch (i.e., by quickly releasing <meta> after launching with <meta>+<key>, where <meta> controls the hidden state).

[l-mb]

I've also just encountered this on openSUSE Tumbleweed.

wmenu-0.1.9-1.3.x86_64
sway-1.11-9.1.x86_64
swaybar-1.11-9.1.x86_64

The workaround of removing the "hide" option works.

[AltGr]

Same issue ; thanks for finding the cause.
Commenting to share my current workaround:

bindsym $mod+d exec "sleep 0.2; bemenu-run $bemenu_params"