I don't know if this is a KWin Wayland protocol bug, or a bug in how Flutter/NativeShell interprets Wayland events. SUMMARY On KWin Wayland, in the NativeShell (Rust Flutter) example app, if you have a menu open and click on another window to close the menu, hovering another menu item causes the menu to reopen. STEPS TO REPRODUCE Setup: 1. Start a Plasma Wayland session and open some random windows. 2. Install Rust, Flutter, and NativeShell: https://github.com/nativeshell/nativeshell/blob/main/README.md#getting-started 3. `git clone https://github.com/nyanpasu64/nativeshell-examples.git -b kwin-wayland-menu-bug` (points to a revision prior to a workaround being added) 4. In the folder, `cargo run --release`. Alternatively, download and run my build at https://www.dropbox.com/s/2xdh3qxlbmjv66p/nativeshell_examples%20kwin%20wayland%20broken.tar.zst?dl=1. (I tested it to work on machines without Flutter installed, but was built on Arch Linux, so may depend on recent glibc.) Steps: 0. (Ignore the likely-corrupted graphics and broken menu text and errors in the terminal.) 1. In the NativeShell Examples app, click the "Menu & MenuBar" tab. 2. Click any menu (like File), then click another window. This should close the menu. (Optionally click another window a second time to defocus NativeShell Examples.) 3. Hover another menu (like Edit). OBSERVED RESULT The menu reopens when you hover a menu item. EXPECTED RESULT The menu doesn't reopen after closing. I do not get this behavior on Weston. I get somewhat different behavior on GNOME Mutter Wayland (ignoring the catastrophic graphical corruption, step 3 does *not* open the menu you hover, but clicking also doesn't work!) In my downstream bug report at https://github.com/nativeshell/examples/issues/13, I wasn't sure if this is due to KWin Wayland failing to deliver the events that the Wayland protocol mandates, Flutter misinterpreting KWin Wayland's events, or NativeShell misinterpreting a set of events sent from Flutter. (Note that on Wayland, NativeShell runs natively and *not* on XWayland.) The author responded: > TBH I don't know if this is issue with Kwin or Gtk. The selection-done event on GtkMenuShell is not delivered when it should be, but I haven't had time to look into why it didn't. I just added a workaround to detect the situation and fix it. I'm not sure if it's a KWin Wayland bug, and don't know enough about desktop protocols to intercept the events and diagnose myself, but decided to report it here anyway. WAYLAND_DEBUG=1 "works" but produces a firehose of mouse-move events I didn't try filtering myself. In any case, NativeShell has worked around this problem in https://github.com/nativeshell/nativeshell/pull/24, which fixes the incorrect behaviors on both KWin and GNOME Mutter. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.2 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 Kernel Version: 5.12.12-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2 (This bug is also reproducible on a laptop with Mesa Intel® HD Graphics 520 (SKL GT2).) ADDITIONAL INFORMATION
"selection done" isn't a valid wayland term. It's worth remembering that Flutter pipes through GTK so there's a layer of indirection. There is an xdg_popup::popup_done your WAYLAND_DEBUG=1
If it works with WAYLAND_DEBUG=1 I don't see how it can be a kwin bug. Everything points to your side. Please reopen if you can point to something more specific.