GNOME Bugzilla – Bug 758283
mouse events are sent to a different screen after window focus switching (for xwayland apps)
Last modified: 2016-10-25 17:27:34 UTC
See the attached video. I have firefox on right screen (primary), hexchat on left screen. Running on Wayland, both are XWayland applications. Hexchat is opened on "/query name" screen, so that it reacts to middle mouse button (shows a menu). I start clicking the middle mouse button in Firefox. After one or two clicks, the rest of the clicks are forwarded not to Firefox, but to Hexchat, to exactly the same cursor position, but on a different screen. We have reproduced exactly the same bug on a different computer as well (also using Firefox and Hexchat), it just took a little longer (had to click 5-10 times before the event was redirected to the wrong screen). So it seems like a race condition. I can provide any debug info that you find useful. gnome-shell-3.18.2-1.fc23.x86_64 mutter-3.18.2-1.fc23.x86_64 xorg-x11-server-Xwayland-1.18.0-2.fc23.x86_64 firefox-42.0-2.fc23.x86_64 hexchat-2.10.2-4.fc23.x86_64
Created attachment 315826 [details] bug demonstration video
Today it's much harder for me to reproduce this - I had to click the middle mouse 20-30 times before it occurred. So it's definitely a race. However, I also once seen the same issue with left mouse click - instead of highlighting a few lines in Firefox, I had a few lines highlighted in hexchat on a different screen. So this is not exclusive to middle mouse click - left mouse click (and probably any mouse click) is affected as well.
This might be relevant: https://bugzilla.gnome.org/show_bug.cgi?id=758342
I'm seeing this issue too, even with just a single screen attached to my computer and 2 applications half-maximized. Doesn't need hexchat to trigger this, not sure about Firefox. Happens very rarely. gnome-shell-3.20.3-3.fc24.x86_64 mutter-3.20.3-1.fc24.x86_64 xorg-x11-server-Xwayland-1.18.3-6.fc24.x86_64 firefox-47.0.1-2.fc24.x86_64
This still happens for me, very often, and I can reproduce this any time on will. Just switch between workspaces (on my right screen) and click shortly afterwards, very often the click is sent to a different screen (the left screen). Could anyone please look into this? It's quite inconvenient. mutter-3.22.0-2.fc25.x86_64 gnome-shell-3.22.0-1.fc25.x86_64
I can provide any debug logs that could be helpful, just tell me which ones.
Could you describe the exact steps, including the setup? I.e. whats your monitor configuration (which one is primary etc), then step by step to reproduce. By just switching workspace and clicking on different monitors I can't reproduce it. Otherwise, if you have two Wayland clients, logs that would be helpful is the log of the client that gets the phantom click. I.e. if you have two clients, on on the right, on the left; trigger the bug without ever actually ever moving the pointer over client you are logging.
I wanted to create a screencast, but https://bugzilla.redhat.com/show_bug.cgi?id=1384482 prevents me from doing so :-/ So, a text description: 1. two 1920x1080 monitors, primary right, secondary left 2. firefox on primary (first workspace, other workspaces empty), hexchat on secondary, both maximized 3. Use Win+2 to switch to the second workspace and Win+1 to go back to first workspace. Once the animation is done (firefox is visible), move the cursor just a little bit (it seems a slight movement is necessary) and right click. Usually you get a right-click menu in Firefox, but once in 5-20 attempts, I get a context menu in hexchat (at the exact same cursor position, just a different screen). 4. Repeat until reproduced :-) Then, I tried with hexchat closed, and left screen either empty or with maximized terminal (wayland native app). Both cases behaved the same. Once in 20 attempts, I see a situation where right click in Firefox didn't do anything (didn't bring up a menu), even after multiple clicks. However, the click didn't seem to propagate to the left screen (I didn't see a context menu of the empty desktop or the terminal). In order to show the context menu in Firefox, I had to move the cursor a bit and then right click again. Finally, I tried having hexchat and terminal on the left screen, hexchat under the terminal (both maximized). After repeating the procedure, I saw a hexchat menu pop up *through* the terminal. So there was hexchat lowest in the window stack, terminal above it, and hexchat right click menu above that. My current theory is that this affects only XWayland apps. Both firefox and hexchat are XWayland. It seems that there's a short period during which the mouse event is sent to a different XWayland app when switching workspaces and/or app focus. If there's no other XWayland app running (like the case when I had only Firefox running, or Firefox + terminal), the event is lost. I tried to create a wayland debug log for hexchat receiving the input event that it was not supposed to, but if I run "WAYLAND_DEBUG=1 hexchat", I see no output in terminal. How can I provide wayland debug logs for XWayland apps?
Thanks for the detailed description Kamil. Getting WAYLAND_DEBUG logs from Xwayland is annoyingly complicated. What you could do however is to log *everything* but only the server, i.e. start gnome-shell with WAYLAND_DEBUG=server. You'd probably need to start gnome-shell without gnome-session from a VT so that the logs can be written directly to a file. Anyway, I will try your reproduction steps tomorrow and will report whether I succeed reproducing or not.
Screencasting has been fixed, I can finally record the issue. This is the basic use case, hexchat context menu shown when right-clicking in firefox: https://www.youtube.com/watch?v=59kdZOA8k8U This is the same, with hexchat overlapped with gnome terminal, but the context menu still showing through: https://www.youtube.com/watch?v=Jj2YZ5jRmg4 And this is hexchat context menu showing on the wrong screen, over Firefox window (I've seen this for the first time): https://www.youtube.com/watch?v=i-7jY3SipoY
Oh, I've finally discovered how it works. It's not a race condition at all. This is a 100% reliable reproducer: 1. have the usual setup (hexchat left, firefox right) 2. switch to second workspace (empty or not, should not matter) 3. move the mouse 4. switch to the first workspace while *not moving the mouse* 5. perform a right click while *not moving the mouse* 6. the context menu will appear over hexchat (instead over firefox) 7. you can repeat 6) multiple times, just use esc to cancel the menu (remember, do not move the mouse) 8. move the mouse 9. perform a right click, see that in is correctly sent to firefox instead of hexchat Here's a video showing it: https://www.youtube.com/watch?v=4IhLrdBXst8 The same thing happens not only after workspace changes, but also after window focus changes. You can reproduce this issue like this: 1. hexchat left, firefox + nautilus right 2. focus nautilus 3. use alt+tab or shell overview to focus firefox, but do not move the mouse cursor (if you use shell overview to switch focus, you must not move cursor after clicking) 4. right click on top of firefox, see hexchat context menu pop up If you try to same thing while right clicking in nautilus, the bug does not happen (because it's native wayland app, not xwayland app). ************* So, overall, it seems that after every window focus change, the cursor is teleported to the left screen. It's location is updated to the real position only after you move the mouse. So if you perform any event before moving the cursor (left/right/middle click, scroll), it is sent to the invalid (teleported) cursor location to the left screen. This only happens for XWayland apps. *************
This is an xwayland bug: https://patchwork.freedesktop.org/patch/118152/