Bitwig Studio tooltips make buttons unclickable

[mzanibelli]

• Sway Version:

  • 1.6 (Arch 1:1.6-1)

• Debug Log:

  • https://gist.github.com/mzanibelli/1174a0ea6c3659e840ee979e18bd6d27

• Configuration File:

  • https://gist.github.com/mzanibelli/a7895d725b4919df3ce8e75a63b5cda2 (default shipped on Arch)

• Description:

When using Bitwig Studio (digital audio workstation) in XWayland, there is an annoying bug as soon as a "tooltip" (little window containing help text about the thing the mouse currently hovers) appears that make the button not clickable anymore. These tooltips usually appear after 1-2 seconds of immobility over the button. If the user clicks before tooltip appears, the expected behavior occurs. If the user clicks after the tooltip becomes visible on the screen, subsequent clicks have no effect.

This looks like a focus bug which would make the mouse act upon the tooltip instead of the underlying button.

I've recorded a GIF showing this exact problem.

In this GIF, I try to click on the "Auto-monitor" orange checkbox located bottom left. As you can see, if I wait, I am not able to change the state of the button.

Side note: I currently run this program in Weston when I need to get things done, where this bug does not occur.

Many thanks for looking into this, let me know if I can be of any help.

Keep Sway amazing :smile:

[ghost]

I suspected that somehow the focus is passed to the unmanaged surface that is the tooltip in Bitwig. So I dug in the code, did some trial and error: removing the code that focuses the surface solved the problem in Bitwig. Of course this breaks all cases where wlr_xwayland_or_surface_wants_focus is correct. This was enough digging for a while, any feedback is appreciated.

diff --git a/sway/desktop/xwayland.c b/sway/desktop/xwayland.c
index 40288f97..27593ed2 100644
--- a/sway/desktop/xwayland.c
+++ b/sway/desktop/xwayland.c
@@ -85,10 +85,10 @@ static void unmanaged_handle_map(struct wl_listener *listener, void *data) {
        desktop_damage_surface(xsurface->surface, surface->lx, surface->ly, true);

        if (wlr_xwayland_or_surface_wants_focus(xsurface)) {
-               struct sway_seat *seat = input_manager_current_seat();
-               struct wlr_xwayland *xwayland = server.xwayland.wlr_xwayland;
-               wlr_xwayland_set_seat(xwayland, seat->wlr_seat);
-               seat_set_focus_surface(seat, xsurface->surface, false);
+               // struct sway_seat *seat = input_manager_current_seat();
+               // struct wlr_xwayland *xwayland = server.xwayland.wlr_xwayland;
+               // wlr_xwayland_set_seat(xwayland, seat->wlr_seat);
+               // seat_set_focus_surface(seat, xsurface->surface, false);
        }
 }

[emersion]

wlr_xwayland_or_surface_wants_focus relies on window type heuristics so it's kind of bound to fail. It would be much nicer to rely on wlr_xwayland_icccm_input_model instead, or find the correct bits to check, but I haven't managed to do this yet.

[mzanibelli]

Awesome work! I had the feeling this was a "fix 1, break 10 use cases" kind of bug. It's not critical but I have to admit it's getting on my nerves, when you're making a pause to think you can't click :sweat_smile:

Anyways I feel a bit guilty not trying to investigate this myself but, if you're comfortable with the codebase, may I suggest checking what Weston does as it seems to get it right?

[emersion]

Weston doesn't handle these cases correctly. Maybe looking at Mutter would be worthwhile.

[ghost]

It feels like the flags for the tooltip-xsurface are wrong:

(gdb) print wlr_xwayland_icccm_input_model(xsurface)
$11 = WLR_ICCCM_INPUT_MODEL_PASSIVE
(gdb) print xsurface->xwm->atoms && WM_HINTS
$13 = 1

_Passive and Locally Active clients set the input field of WMHINTS to True, which indicates that they require window manager assistance in acquiring the input focus. No Input and Globally Active clients set the input field to False, which requests that the window manager not set the input focus to their top-level window.

ICCCM

As I understand this, according to the flags sway is doing the right thing: setting the focus.

The tooltip is few pixels to the right and below of the cursor, wouldn't that mean that the click misses the tooltip-surface and is sent to the surface below? Sorry, I wasn't able to find out if wayland is supposed to work like this. At least the size of the tooltip seems to be synchronized with sway.

(gdb) print xsurface->surface->current->width
$34 = 51
(gdb) print xsurface->surface->current->height
$35 = 22

[ghost]

@mzanibelli I think it will take a while till I understand wayland, xwayland and sway good enough to fix the problem or someone else finds a solution. So I created a workaround. It is not nice and since my sway setup isn't ready, I didn't test it well enough: let me know if it breaks something else in Bitwig.

[mzanibelli]

Hello @davidsonder, I quickly tested your workaround yesterday and I confirm it seems to work. I'll try to have a longer session with it during the coming days to ensure it does not break something. Thanks for your help on this 🚀

[mzanibelli]

Hello :smile: Chiming in to confirm the bug still occurs in 1.8.1, and that this Hyprland WM seems to have it fixed (or at least circumvent) despite being wlroots-based. Graphically, using their default config, we can see that as soon as the tooltip appears the parent window loses focus (because it's not highlighted anymore) but the click event seems to be correctly routed anyway. I wholeheartedly hope this can take the investigation further :muscle:

[felixniemeyer]

I have the same issue! I have found out that I can close tooltips with the ESC key and then click as a workaround.

However, there are two other issues in bitwig on sway:

• Menus close completely when submenu looses focus. (e.g. when selecting input source for a track)
• Can't create stretch marker by double clicking on the waveform

I wrote an email to bitwig a few months ago about this, and received the following answer:

Hi Felix​,
​
thanks for your report, we will forward it to the dev team. Unfortunately we officially only support Ubuntu and such issues are often caused by slight differences by the different desktop and window manager systems and fixing it for one often means breaking something for another again.

Best regards,
Bitwig Technical Support Team

I'll send them this issue here on github, too! :)