Created attachment 171993 [details] video showcasing the issue SUMMARY Menu bar in GTK apps does not behave correctly in Plasma under Wayland. Please see the attached video. You can clearly see that I am clicking the Tools menu, but the Files menu is opening instead. The only way to open the menu under the mouse cursor is to actually move the mouse after clicking on the menu bar. The app in the video is Emacs built with the PGTK option (pure GTK/Wayland), but I experience the same behaviour in other GTK+ apps, e.g. Xournal++, DeaDBeeF (audio player) etc. The issue appears to be Wayland-specific, the menu bar behaves correctly if I use Plasma with X11. Needless to say, the same apps behave correctly in GTK-based environments, e.g. GNOME. STEPS TO REPRODUCE 1. Login into the Plasma-Wayland session 2. Open a GTK+ app, e.g. Xournal++ or Emacs PGTK 3. Click in the menu bar on any submenu that is not the first menu in the list OBSERVED RESULT When the user clicks in the menu bar, the first submenu (which is typically Files) opens instead of the submenu that has actually been clicked. To actually open the menu under the cursor, the user has to move the mouse after the menu bar has been clicked. EXPECTED RESULT Click opens the submenu under the cursor. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240724 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.9-1-default (64-bit) Graphics Platform: Wayland
Can reproduce the issue in Inkscape too.
Created attachment 172211 [details] WAYLAND_DEBUG=1 log on KWin Log from KWin, where it happens.
Created attachment 172212 [details] WAYLAND_DEBUG=1 log on Weston Log from Weston, where it doesn't happen.
(In reply to Nate Graham from comment #2) > Created attachment 172211 [details] > WAYLAND_DEBUG=1 log on KWin > > Log from KWin, where it happens. [ 39389.249] wl_pointer@21.motion(92984635, 497.17187500, 15.31250000) [ 39389.308] wl_pointer@21.frame() [ 39597.188] wl_pointer@21.button(289571, 92984843, 272, 1) [ 39597.237] wl_pointer@21.frame() [ 39606.626] -> wl_pointer@21.set_cursor(289562, wl_surface@26, 6, 6) [ 39606.666] -> wl_surface@26.attach(wl_buffer@53, 0, 0) [ 39606.679] -> wl_surface@26.set_buffer_scale(1) [ 39606.688] -> wl_surface@26.damage(0, 0, 48, 48) [ 39606.696] -> wl_surface@26.commit() [ 39613.845] -> wl_compositor@4.create_surface(new id wl_surface@57) [ 39613.921] -> wl_surface@57.set_buffer_scale(3) [ 39614.028] -> wl_surface@57.set_buffer_scale(3) [ 39615.008] -> xdg_wm_base@28.create_positioner(new id xdg_positioner@52) [ 39615.028] -> xdg_positioner@52.set_size(232, 338) [ 39615.038] -> xdg_positioner@52.set_anchor_rect(466, 0, 47, 27) [ 39615.046] -> xdg_positioner@52.set_offset(0, 0) [ 39615.054] -> xdg_positioner@52.set_anchor(6) [ 39615.061] -> xdg_positioner@52.set_gravity(8) [ 39615.068] -> xdg_positioner@52.set_constraint_adjustment(59) [ 39615.076] -> xdg_wm_base@28.get_xdg_surface(new id xdg_surface@58, wl_surface@57) [ 39615.085] -> xdg_surface@58.get_popup(new id xdg_popup@51, xdg_surface@41, xdg_positioner@52) [ 39615.094] -> xdg_positioner@52.destroy() [ 39615.104] -> xdg_popup@51.grab(wl_seat@22, 289571) [ 39615.114] -> wl_surface@57.commit() [ 39621.485] -> xdg_popup@51.destroy() [ 39621.521] -> xdg_surface@58.destroy() [ 39621.530] -> wl_surface@57.destroy() [ 39626.490] -> wl_pointer@21.set_cursor(289562, wl_surface@26, 6, 6) [ 39626.514] -> wl_surface@26.attach(wl_buffer@53, 0, 0) [ 39626.523] -> wl_surface@26.set_buffer_scale(1) [ 39626.529] -> wl_surface@26.damage(0, 0, 48, 48) [ 39626.536] -> wl_surface@26.commit() [ 39633.002] -> wl_compositor@4.create_surface(new id wl_surface@56) [ 39633.046] -> wl_surface@56.set_buffer_scale(3) [ 39633.125] -> wl_surface@56.set_buffer_scale(3) [ 39634.649] -> xdg_wm_base@28.create_positioner(new id xdg_positioner@59) [ 39634.668] -> xdg_positioner@59.set_size(312, 488) [ 39634.678] -> xdg_positioner@59.set_anchor_rect(0, 0, 39, 27) [ 39634.686] -> xdg_positioner@59.set_offset(0, 0) [ 39634.693] -> xdg_positioner@59.set_anchor(6) [ 39634.700] -> xdg_positioner@59.set_gravity(8) [ 39634.707] -> xdg_positioner@59.set_constraint_adjustment(59) [ 39634.716] -> xdg_wm_base@28.get_xdg_surface(new id xdg_surface@60, wl_surface@56) [ 39634.725] -> xdg_surface@60.get_popup(new id xdg_popup@61, xdg_surface@41, xdg_positioner@59) [ 39634.735] -> xdg_positioner@59.destroy() [ 39634.745] -> xdg_popup@61.grab(wl_seat@22, 289571) [ 39634.757] -> wl_surface@56.commit() [ 39646.285] -> wl_shm@7.create_pool(new id wl_shm_pool@62, fd 18, 8079360) [ 39646.331] -> wl_shm_pool@62.create_buffer(new id wl_buffer@63, 0, 1920, 1052, 7680, 0) [ 39666.509] -> wl_surface@33.attach(wl_buffer@63, 0, 0) [ 39666.548] -> wl_surface@33.set_buffer_scale(1) [ 39666.559] -> wl_surface@33.damage(0, 0, 1920, 1052) [ 39666.567] -> xdg_toplevel@42.set_min_size(707, 440) [ 39666.573] -> xdg_toplevel@42.set_max_size(0, 0) [ 39666.591] -> xdg_surface@41.set_window_geometry(0, 0, 1920, 1052) [ 39666.969] -> wl_surface@33.frame(new id wl_callback@64) [ 39666.981] -> wl_surface@33.commit() [ 39667.074] wl_display@1.delete_id(52) [ 39667.086] wl_display@1.delete_id(51) [ 39667.093] wl_display@1.delete_id(58) [ 39667.099] wl_display@1.delete_id(57) [ 39667.106] wl_display@1.delete_id(59) [ 39667.113] xdg_popup@61.configure(0, 27, 312, 488) so what happens is the following: - kwin sends a button press at 497.17187500, 15.31250000 - inkscape creates a popup menu with anchor rect `466,0 47x27` - so far so good, but then it **immediately** destroys that popup and creates a new one with the anchor rect `0,0 39x27` this is not right and points to the client. This might be a gtk bug. It's interesting why the behavior is different when using kwin and weston. My guess is that the difference comes to test environment differences, e.g. maybe different output layouts, etc. As far as I can tell, kwin doesn't do anything wrong. Can you please report this issue to GTK developers?
Sorry to necro an old bug, but I recently got a chance to test this issue in other Wayland compositors, and I can confirm that GTK's menu bar behaves correctly in Gnome/Mutter, Niri and Sway (all installed on the same machine). I have not tested other compositors, but the fact that KWin is the only compositor which reliably shows the issue makes me think that the issue is KWin-related.
*** Bug 500199 has been marked as a duplicate of this bug. ***
*** Bug 500264 has been marked as a duplicate of this bug. ***
Compositors work differently, they can send events in different order triggering different code paths in client. Given the events that kwin sends, the menubar menus should work as expected.
Fixed upstream https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8240
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7241
*** Bug 500804 has been marked as a duplicate of this bug. ***
Git commit 0de2b76bcb19ce459a6dc99635889de47bba53c5 by Vlad Zahorodnii. Committed on 27/02/2025 at 14:03. Pushed by vladz into branch 'master'. plugins/buttonrebinds: Create input device on demand M +15 -9 src/plugins/buttonrebinds/buttonrebindsfilter.cpp M +1 -1 src/plugins/buttonrebinds/buttonrebindsfilter.h https://invent.kde.org/plasma/kwin/-/commit/0de2b76bcb19ce459a6dc99635889de47bba53c5
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7244
Git commit 32cb9df75227a7a8ecadd3dda79acf2cf385170f by Vlad Zahorodnii. Committed on 27/02/2025 at 15:00. Pushed by vladz into branch 'Plasma/6.3'. plugins/buttonrebinds: Create input device on demand (cherry picked from commit 0de2b76bcb19ce459a6dc99635889de47bba53c5) Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> M +15 -9 src/plugins/buttonrebinds/buttonrebindsfilter.cpp M +1 -1 src/plugins/buttonrebinds/buttonrebindsfilter.h https://invent.kde.org/plasma/kwin/-/commit/32cb9df75227a7a8ecadd3dda79acf2cf385170f
*** Bug 501137 has been marked as a duplicate of this bug. ***
(In reply to Vlad Zahorodnii from comment #14) > Git commit 32cb9df75227a7a8ecadd3dda79acf2cf385170f by Vlad Zahorodnii. > Committed on 27/02/2025 at 15:00. > Pushed by vladz into branch 'Plasma/6.3'. > > plugins/buttonrebinds: Create input device on demand > > > (cherry picked from commit 0de2b76bcb19ce459a6dc99635889de47bba53c5) > > Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org> > > M +15 -9 src/plugins/buttonrebinds/buttonrebindsfilter.cpp > M +1 -1 src/plugins/buttonrebinds/buttonrebindsfilter.h > > https://invent.kde.org/plasma/kwin/-/commit/ > 32cb9df75227a7a8ecadd3dda79acf2cf385170f I verify the fix on Arch Linux, thanks!
> I verify the fix on Arch Linux, thanks! Still happening on OpenSUSE Tumbleweed 20250315 with Plasma 6.3.3, tested in Emacs, Inkscape and the recently released GIMP 3.0.0
Can still reproduce the menu issue with Gimp 3.0, running on Plasma 6.3.3 on Kubuntu 25.04-dev. From my understanding, if https://invent.kde.org/plasma/kwin/-/merge_requests/7244 was intended to fix it, then it does not for me. To make the problem go away, I had to delete a mouse button rebind from ~/.config/kcminputrc I briefly tested if I could reproduce the menu issue with other GTK3 apps I have installed (Inkscape, Audacious in GTK mode), but have seen it only with Gimp so far. For refererence, there is also a thread on KDE Discuss: https://discuss.kde.org/t/gimp-3-menu-plasma-bug/31770
Jan, thank you for this information. I can confirm that the issue is gone for me if I remove my pen tablet button rebinds from kcminputrc. Which is, of course, not ideal, especially considering that I regularly use GIMP with my pen tablet. However, the issue will be moot once distributions start shipping GTK 3.24.49. OpenSUSE Tumbleweed recently updated their GTK3 to the aforementioned version, and on my Tumbleweed machine I no longer have the issue in any GTK3 app, even with the tablet bindings still active.