sfwbar bluetooth tray menu can't be interacted with

[kode54]

Describe the bug
sfwbar has a bluetooth menu that can be used to connect, disconnect, or pair devices. Unfortunately, I cannot interact with the submenus, as clicking on the menu dismisses it under Wayfire.

To Reproduce
Steps to reproduce the behavior:

1. Use mostly default settings
2. Install sfwbar
3. Configure sfwbar to default settings, but uncomment the bluetooth widget
4. Left click the Bluetooth logo on the tray
5. Attempt to right click the devices listed in the menu

Expected behavior
The right click on the menu items should open the sub-menu to allow manipulating the devices.

Screenshots or stacktrace
Here's a WAYLAND_DEBUG log from sfwbar:
sfwbar_wldebug.log.txt

Wayfire version
wayfire-git 0.8.1.r302.g5b4f9b94-1

[kode54]

I'll see if I can get some WAYLAND_DEBUG logs for this too. Should require less effort on my part to capture events from the menu, than to ask someone else to do it.

[kode54]

Attached a debug log.

[ammen99]

I just checked this, sfwbar seems to behave very weirdly. When you click on the popup, it grabs keyboard input (by setting exclusive keyboard input) but then ungrabs it immediately. In wayfire, this triggers a focus change event (as it should) and wayfire closes the popups of an application when the focus moves away from the app. I consider this a bug in the app itself - why does sfwbar grab the keyboard in this case??

[kode54]

This appears to be where sfwbar is taking focus?

https://github.com/LBCrion/sfwbar/blob/main/src/popup.c#L245

[LBCrion]

Sfwbar takes focus in base_widget_get_modifiers around https://github.com/LBCrion/sfwbar/blob/main/src/basewidget.c#L138 .

This is done as a workaround for poor handling of the layer shell ON_DEMAND keyboard mode in some compositors. Some compositors handle ON_DEMAND mode as EXCLUSIVE, resulting in a complete lock-out of the keyboard input (i.e. you need to remote into the box and kill an app using ON_DEMAND mode).

Sfwbar polls keyboard modifiers on mouse clicks to allow mapping actions to Modifier+Click events. I.e. it requests keyboard interactivity, checks the modifier state and releases the interactivity.

What's interesting that none of the other compositors I've worked with close popups on focus-out. Implementing this behavior in gtk is a rather messy task on it's own (it's implemented as an optional behaviour in sfwbar).

[ammen99]

@LBCrion why not grab keyboard with a popup grab?

[LBCrion]

Grabs for layer shell popups are hit and miss on most compositors. Sfwbar uses popup grabs for autoclosing popup windows, but in most cases, the keyboard doesn't get grabbed (same is true for gtk menues attached to a layer shell toplevel), so the user can dismiss a popup by clicking outside of the window, but not by pressing escape.

[ammen99]

Grabs for layer shell popups are hit and miss on most compositors. Sfwbar uses popup grabs for autoclosing popup windows, but in most cases, the keyboard doesn't get grabbed (same is true for gtk menues attached to a layer shell toplevel), so the user can dismiss a popup by clicking outside of the window, but not by pressing escape.

Fair point, Wayfire only recently implemented such grabs - but I would still argue it is better to use them and push compositors towards implementing all features :)

In #2382 I changed the popup closing logic a bit and hopefully wayfire wouldn't close the popups after those changes.