bemenu isn't visible when another application is fullscreen

[AdrienLemaire]

versions:

• OS: Arch linux
• sway 1:1.2-5
• bemenu-git r303.98f7c80-1

Expected behavior: Triggering bemenu while another app is fullscreen should display bemenu on top of the full-screen application

Current behavior: bemenu is shown behind the fullscreen application.

In web dev, it would be a matter of bumping the css z-index property. In wayland/X11, no idea ^^

Note: the manpage mentionned an -n parameter (--no-overlap) for wayland, but using it still doesn't show bemenu while another app is fullscreen

[Cloudef]

https://github.com/Cloudef/bemenu/blob/master/lib/renderers/wayland/window.c#L327 Does changing the ZWLR_LAYER_SHELL_V1_LAYER_TOP to ZWLR_LAYER_SHELL_V1_LAYER_OVERLAYwork here? If not, this is a sway / wlr protocol issue and you should open a issue there. You can read how the wayland protocol for bemenu window works here https://github.com/Cloudef/bemenu/blob/master/lib/renderers/wayland/wlr-layer-shell-unstable-v1.xml

[AdrienLemaire]

$ git clone https://github.com/Cloudef/bemenu.git
$ cd bemenu
$ sed -i 's/V1_LAYER_TOP/V1_LAYER_OVERLAY/g' lib/renderers/wayland/window.c
$ mkdir -p build/usr/lib && cd build
$ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=usr -DCMAKE_INSTALL_LIBDIR=usr/lib -DBEMENU_X11_RENDERER=OFF -DBEMENU_WAYLAND_RENDERER=ON ..
$ make install
$ ls | ./usr/bin/bemenu

Menu still hidden behind the fullscreen alacritty window.

After reading sway(5), I tried to add popup_during_fullscreen to my sway config, set to "smart" then "leave_fullscreen". It didn't have any effect. Indeed, I have the same issue with notify_send (mako), so this is not a bemenu issue.

[tmccombs]

@AdrienLemaire did you create an issue in sway or wlroots for this?

[AdrienLemaire]

@tmccombs not yet, it's kinda low in my priorities atm ^^

[travankor]

Does changing the ZWLR_LAYER_SHELL_V1_LAYER_TOP to ZWLR_LAYER_SHELL_V1_LAYER_OVERLAYwork here?

This works, but this can be a privacy/security issue since bemenu with OVERLAY will show up on top of a screen locker (ie: Run bemenu-run, then leave your computer. swayidle locks the screen. Random person shows up and can run an arbitrary command thanks to bemenu being open).

[Cloudef]

Does changing the ZWLR_LAYER_SHELL_V1_LAYER_TOP to ZWLR_LAYER_SHELL_V1_LAYER_OVERLAYwork here?

This works, but this can be a privacy/security issue since bemenu with OVERLAY will show up on top of a screen locker (ie: Run bemenu-run, then leave your computer. swayidle locks the screen. Random person shows up and can run an arbitrary command thanks to bemenu being open).

This sounds like protocol issue. The OVERLAY here works as documented I guess, but another parameter like OVERLAY_UNLOCKED or such to make the overlay only on top if it's a unlocked session could be a good idea. Though not sure, you should maybe ask #sway or write issue to wlroots if this behavior of OVERLAY is desired. It seems like it could've been overlooked as well, and any application could use this protocol to bypass screenlocker as it is currently.

[travankor]

Though not sure, you should maybe ask #sway or write issue to wlroots if this behavior of OVERLAY is desired. It seems like it could've been overlooked as well, and any application could use this protocol to bypass screenlocker as it is currently.

https://github.com/swaywm/swaylock/issues/107 The current behavior is intentional. It would be nice to have an extra field, like you said, or have a way to define relative ordering in the same layer.

Not sure if/how input-inhibit is working correctly since I can still type things as long as the previous OVERLAY application is focused before the screen locks.

[Cloudef]

The ordering might make more sense if it's user configurable. E.g. in sway's configuration. I can't think of any sane way for applications to define their ordering, since most applications likely would either default on "BOTTONMOST or TOPMOST", so having it undefined is good I think, but making it configurable in compositor would be ideal.

[cronyakatsuki]

Hi I just wanted to ask is there anything being done with this issue?

Every other dmenu like program work's with fullscreen apps but bemenu doesn't.

[merrittlj]

I can look into it, but I'm unsure about how simple it might be.

[tmccombs]

On sway 1.8, I think using the overlay layer no longer has concerns with showing above the screen locker, since sway and swaylock now use the ext-session-lock protocol, so non-lock applications shouldn't be shown above the lockscreen.

[DoctorKnowsBetter]

Dear developers, we really need this feature. Otherwise, working in full-screen mode is very difficult. The entire Sway community will be immensely grateful to you!

[Cloudef]

I haven't done any wayland related for a while. Most of the wayland specific contributions to bemenu have come from other great individual contributors. AFAIK the current situation is that this is a protocol issue so it should be solved in protocol level, sway and then bemenu (if code changes is needed). Correct me if wrong, it could also be that the protocols in bemenu need to be updated to latest versions.

[fictitiousexistence]

@Cloudef Not sure if this will help anything or anyone however, it appears like it's not an issue with bemenu.

I was originally on sway and found this issue to occur. I then started using kickstart launcher which magically worked over fullscreen apps.

I switched over to hyprland as well.

I had some issues with kickstart and went back to bemenu, forgetting about the fullscreen issue.

Surprisingly bemenu worked over fullscreen apps in hyprland! Then it stopped.

I started testing out dwl and found the issue did not exist there.

Then I opened an issue with hyprland and the dev fixed it instantaneously. https://github.com/hyprwm/Hyprland/commit/0314a727eb27dd880b172b9ff2dc78c863f3ce5f

Sooooo thanks for all the work you put into bemenu and the fullscreen issue seems to be fixed. :D