SUMMARY When wine application creates tray icon, xembedsniproxy creates invisible proxy window 0x0 - 32x32. When using application which uses pointer confinement and hovering over area of xembedsniproxy, makes pointer act as if it were not confined. Only way to confine pointer again is to open start menu/application launcher. Something that might be related: On Wayland when there is no other window or there is only wayland window open you can right click xembedsniproxy proxy area to open context menu, but when another X window is open then that window takes priority. This would suggest that xembedsniproxy is not stacked correctly under wayland windows? STEPS TO REPRODUCE 1. Run wine application with tray icon 2. Run any application requiring pointer confinement on top left screen (containing 0x0 coordinates?) 3. Move pointer to top left corner OBSERVED RESULT Pointer confinement no longer works. EXPECTED RESULT Pointer confinement works SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.11 Kernel Version: 6.5.5-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6700 XT Manufacturer: ASUS ADDITIONAL INFORMATION Video: https://youtu.be/YqdcZLHhrrM Games tested: League of Legends, Counter-Strike 2 (with Riot Client working in background) Killing xembedsniproxy makes pointer confinement work correctly. Possibly duplicate of https://bugs.kde.org/show_bug.cgi?id=433079 , but I'm creating this issue maybe it can help people because killing xembedsniproxy is a valid workaround. I couldn't check if confinement works after moving xembedsniproxy window by right-clicking icon on tray bar, because it completely breaks pointer confinement and it never works, but I would say it's another issue, because it still happens after killing xembedsniproxy. I'm using xembedsniproxy with defined VISUAL_DEBUG to show bug better, but it also happens without this define.
It's the same as Bug 433079, yeah. *** This bug has been marked as a duplicate of bug 433079 ***