Closed salkin-mada closed 2 years ago
We confirmed it is a Sway problem by downgrading but just FYI also tested by downgrading Reaper, which did not help, and tried it in Gnome under Wayland where it seems to work fine according to @kflak.
Though, not all dropdowns work fine on sway 1.5 and wlroots 0.12.
For example:
Default
). Sometimes this works, sometimes not. The dropdown itself is unresponsive to mouser hovers sometimes (though keeping the mouse button used to open up the drop down pressed down seems to sometimes make it work). Pressing the +
button to the right of it causes another strange dropdown bug where it sometimes freezes the dropdown.There is an accompanying thread on the Reaper forum about this bug by the way (even though this is an xwayland/sway issue) https://forum.cockos.com/showthread.php?p=2453632#post2453632
parts of the Debug Log mentioning xcb error: op ChangeProperty
and unhandled X11 property (_NET_WM_ICON_NAME)
is found in this wlroots
commit:
In addition to working fine on Gnome wayland, the issue is not present when running on i3.
Commit https://github.com/swaywm/sway/commit/7ca9ef12f8b6a00b8020a500433fabc6b645d85c broke drop-downs from working. Adding it back makes drop-downs work again.
Great catch!
ldd /bin/reaper
does not show any shared objects in regards to GUI base. So what ever it is using it is statically linked. Anyone here knows what its based on? GDK?
GDK 3. The system's libgdk-3.so.0 is loaded at runtime using dlopen
in libSwell.so.
Commit 7ca9ef1 broke drop-downs from working. Adding it back makes drop-downs work again.
I am compiling as a subproject. Even with master. Adding back what was removed in the commit @yrhki referred to does not seem to change any drop down focus behavior on my system. Maybe I am missing something? A couple of commits after 7ca9ef1 has also changed things in `void unmanaged_handle_unmap.
For me what fixes the drop down focus in reaper
is to just comment out
https://github.com/swaywm/sway/blob/bb3fd0abc56f39e35dc7f4e86f25da1b4a6efbd7/sway/desktop/xwayland.c#L118
So why would the focus be set to NULL before being set to previous. ? At least in reaper this seems to close the the drop down or just loose focus when there is a "sub" drop down menu in a drop down menu - that is :).
Will try and see if other X app bugs arise when not setting to NULL if *previous. https://github.com/salkin-mada/sway/tree/drop_down_menu_focus
At least I can use Reaper on sway
again.
@salkin-mada does this work for you?
static void unmanaged_handle_unmap(struct wl_listener *listener, void *data) {
struct sway_xwayland_unmanaged *surface =
wl_container_of(listener, surface, unmap);
struct wlr_xwayland_surface *xsurface = surface->wlr_xwayland_surface;
desktop_damage_surface(xsurface->surface, xsurface->x, xsurface->y, true);
wl_list_remove(&surface->link);
wl_list_remove(&surface->set_geometry.link);
wl_list_remove(&surface->commit.link);
struct sway_seat *seat = input_manager_current_seat();
if (seat->wlr_seat->keyboard_state.focused_surface == xsurface->surface) {
// This simply returns focus to the parent surface if there's one available.
// This seems to handle JetBrains issues.
if (xsurface->parent && xsurface->parent->surface
&& wlr_xwayland_or_surface_wants_focus(xsurface->parent)) {
seat_set_focus_surface(seat, xsurface->parent->surface, false);
return;
}
// Try to find another unmanaged surface from the same process to pass
// focus to. This is necessary because some applications (e.g. Jetbrains
// IDEs) represent their multi-level menus as unmanaged surfaces, and
// when closing a submenu, the main menu should get input focus.
struct sway_xwayland_unmanaged *current;
wl_list_for_each(current, &root->xwayland_unmanaged, link) {
struct wlr_xwayland_surface *prev_xsurface =
current->wlr_xwayland_surface;
if (prev_xsurface->pid == xsurface->pid &&
wlr_xwayland_or_surface_wants_focus(prev_xsurface)) {
seat_set_focus_surface(seat, prev_xsurface->surface, false);
return;
}
}
// Restore focus
struct sway_node *previous = seat_get_focus_inactive(seat, &root->node);
if (previous) {
// Hack to get seat to re-focus the return value of get_focus
seat_set_focus(seat, NULL);
seat_set_focus(seat, previous);
}
}
}
@yrhki Yes! Its works even better with Reaper. Esc
will now close the menu's fully downwards (when having several opened submenu's). Though still having some quite easily discoverable bugs in the VST preset drop downs.
And again vscode
running Xwayland still seems to act nice with its drop downs. - Just as a minimal impact test.
@yrhki . No actually its seems very robust in Reaper. Ok with you to change the title of #6461 and change the commit as a Co-authored-by? Or you want to do something else? test more?
@salkin-mada ok
When VST preset drop down is created and is frozen I noticed that VST window is still in focus. You can see this by trying to interact with the VST over the preset drop down (I used Cobalt to do this).
Should we try and address this somehow? How do you test this with Cobalt?
I am using yabridge
. But the mouse hidden behind a VST (GUI - not Reaper UI) param bug is possibly more a "bridge" and wine version issue.
Sway Version: 1.6
Debug Log: sway -d2>sway.log
Configuration File: Default.
Reproduce
Description: Recently, something has broken drop downs when running Reaper in Sway (XWayland that is).
The symptom is: When you click something that produces a drop down, after scrolling/hovering past the first few items with the mouse, the drop down disappears, making it impossible to use them. This seems to affect all drop downs in Reaper.
The bug is caused by something that was introduced in Sway version 1.6 and the accompanying wlroots 0.13. Downgrading to Sway version 1.5 and wlroots 0.12 and the issue is gone.
@madskjeldgaard and @kflak, please elaborate on these findings if needed.