GNOME Bugzilla – Bug 763246
Applications stop responding to mouse clicks, though menu bar remains responsive
Last modified: 2017-10-31 11:07:33 UTC
While using various applications (Chrome, Firefox, Gimp, LibreOffice Writer) on Fedora 23 in a gnome-wayland session, the window manager seems to ignore mouse clicks on application windows with increasing frequency. Keyboard input continues to function, so I can save work and quit applications. The menu bar continues to accept mouse input, so I am able to logout of the session. After logging back in, the applications are again sensitive to mouse input. This is mutter 3.18.3-1.fc23. Please let me know what else I can provide or try. Regards, Phil
Hi, I also experience this on mutter 3.19.92. Phillip Heller are you using multiple monitors? It happens after docking a Thinkpad x220 with 2 external monitors plugged into the docking station, when on the primary display everything works fine (also works if I move the app there), but the mouse clicks are ignored on the secondary displays. Also I experience it at other times with Firefox/Chrome also on the secondary displays, but I didn't find out what triggers it yet. Also I never experienced it with no external displays connected. Arch linux @ 4.3.6-1-ck Tamas
Tamas, I am using a single monitor attached driven by an AMD FirePro W4100. I found an old report against gnome-shell that describes similar symptoms in the Ubuntu tracker, here: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1181666 Regards, Phil
Ok, I did some tests, I'm not sure if these are related or two separate issues. I'll just describe it maybe it helps and I can create an other ticket if necessary. As I previously wrote it seems to happen after docking and only for Xwayland apps, logout-login solves it. I'm guessing the mouse coordinates are not translated properly in this scenario because I can use the keyboard and the mouse is behaving like when its on the edge of the display.
Happened to me yesterday, however I could regain input by restarting one of the apps.
Also, the mouse cursor change properly when over text/links, but no input was passed to the app. This has been happening to me since 3.16/18 I think.
OK this just happened to me for the shell too. Opening a new x window fixed it.
This happens to me as well once a day on Fedora 24. Only the shell accepts mouse clicks, other applications only respond to the keyboard. Both X and wayland applications are affected and restarting them does not fix the problem.
I have the same (or a similar problem). The used Laptop has an HDPI screen including touch, connected to an additional LCD Monitor. Sometimes (not very frequency) the mouse cursor changes to a hand, and cannot be turned back. Furthermore, I'm no longer able to interact with applications, but are able to interact with the Gnome UI using the mouse (header bar,...). Additionally, keyboard also does no longer work for normal applications, but I can use the search input of Gnome (when accessing it via the mouse). After searching, the mouse cursor changes back to default but the other problems remain.
Hello, I have the same problem too. Fedora 25, mutter 3.22.2, libwayland-server-1.12.0-1 The problem appears only when using a Java app (JRE 1.8.0_31) and after a random time. If I close this window, I can click again in other windows. Regards.
Having the same issue (i.e., left mouse clicks quit getting sent to application, keyboard still works normally). The issue happens randomly with no apparent trigger (typically after working for an hour or two but sometimes more often). Only the application client window and menu bar are affected (title bar still recognizes left clicks to move the window, gnome UI and desktop respond to mouse clicks, settings dialogs seem to work normally). Only seems to affect XWayland applications. Steps tried: 1. Closing application and relaunching does not solve the problem. 2. Once one application quits responding, all other open applications also quit responding. Closing all applications and relaunching does not clear the problem. 3. Logging out and back in does not fix the issue. 4. Rebooting the computer is the only way I have found to clear the issue. Fedora 25, 64-bit mutter 3.22.2-3 libwayland-server 1.12.0-1 Problem occurs in the following apps: Google Chrome, Pycharm Community Edition 2016.3.1, leafpad 0.8.18-1 DB Browser for SQLite 3.9.1 QT Designer 5.7.1 QT Creator 4.1.0 Eclipse Neon.1 4.6.1
Hello, Same problem here. Fedora 25 mutter 3.22.2 Problem occurs mainly with Intellij. It also happens once with Texmaker. Closing the concerned window solves the issue for me.
(In reply to Phillip R Bagwell from comment #10) > Having the same issue (i.e., left mouse clicks quit getting sent to > application, keyboard still works normally). The issue happens randomly with > no apparent trigger (typically after working for an hour or two but > sometimes more often). Only the application client window and menu bar are > affected (title bar still recognizes left clicks to move the window, gnome > UI and desktop respond to mouse clicks, settings dialogs seem to work > normally). Only seems to affect XWayland applications. > > Steps tried: > > 1. Closing application and relaunching does not solve the problem. > 2. Once one application quits responding, all other open applications also > quit responding. Closing all applications and relaunching does not clear the > problem. > 3. Logging out and back in does not fix the issue. > 4. Rebooting the computer is the only way I have found to clear the issue. > If it doesn't help by logging out/in I suspect it is a completely different issue. For the ones who can reproduce, does the new xwayland-1.19.1 version help anything? There was one patch that could possibly affect the cause of this bug, so it'd be good to know if it still reproduces with that version.
I'm using Fedora 25 When running Java app like Sweethome3d, sometimes I cant focus/click on other window and the app's window itself. making desktop locked up. I have to press shortcut Alt F4 to close java app and then desktop back to normal This issue also happen to Openshot (appimage version)
(In reply to Jonas Ådahl from comment #12) > (In reply to Phillip R Bagwell from comment #10) > > Having the same issue (i.e., left mouse clicks quit getting sent to > > application, keyboard still works normally). The issue happens randomly with > > no apparent trigger (typically after working for an hour or two but > > sometimes more often). Only the application client window and menu bar are > > affected (title bar still recognizes left clicks to move the window, gnome > > UI and desktop respond to mouse clicks, settings dialogs seem to work > > normally). Only seems to affect XWayland applications. > > > > Steps tried: > > > > 1. Closing application and relaunching does not solve the problem. > > 2. Once one application quits responding, all other open applications also > > quit responding. Closing all applications and relaunching does not clear the > > problem. > > 3. Logging out and back in does not fix the issue. > > 4. Rebooting the computer is the only way I have found to clear the issue. > > > > If it doesn't help by logging out/in I suspect it is a completely different > issue. > > For the ones who can reproduce, does the new xwayland-1.19.1 version help > anything? There was one patch that could possibly affect the cause of this > bug, so it'd be good to know if it still reproduces with that version. To update my experience: I originally upgraded to Fedora 25 from Fedora 24 using the upgrade process. Prior to the upgrade, I had no issues with losing the left click functionality. The left click problems appeared afterward. I finally just re-formated my ssd and reinstalled Fedora 25 directly, did all the updates and reinstalled all my previous apps. I have been using the system now for about two weeks and have not had any further left click issues and, if fact, the overall system seems much more stable. I'm guessing that something in the upgrade process did not update correctly.
*** Bug 777288 has been marked as a duplicate of this bug. ***
I can confirm this happens randomly on Arch when I use OpenShot video editor. After close OpoenShot, the problem disappears.
It affects me when using IntelliJ IDEA or derivated IDEs in 3.22.3 under Arch Linux.
Are there any reliable reproduction steps, or does it happen only after N amount of time of random usage?
Random, probably for non GTK apps like Java, kde (Xwayland?)
(In reply to Jonas Ådahl from comment #18) > Are there any reliable reproduction steps, or does it happen only after N > amount of time of random usage? If it helps it happened to me when I alt+tabbed back to the IDE. Ctrl + Alt + F1 solved the problem everytime.
So, the issue at hand, most likely is as mentioned a stuck pointer grab, held by some client. This happens sometimes on pure X11 as well, with the difference that there will be no Wayland clients that still work and possibly more nasty side effects. While I'm speculating here, as I haven't reproduced this myself yet, the reason it fixes itself when switching back and forth to a VT is probably that on a VT switch, all of the input devices are destroyed (the compositor will loose access to the file descriptors, close them); this is picked up by Xwayland which will also destroy its input devices. When Xwayland destroyes its input devices, there is no input devices that can have any stuck grabs on them, meaning the grab is implicitly broken. When returning from VT, the compositor and Xwayland will have created new fresh devices, and inside Xwayland, the new device will no longer have the stuck grab. The reason it seems to happen in Xwayland and not on X11 is that, from a client perspective, there are subtle differences in what it'll receive. For example, a X11 client running on Xwayland that opens a menu will create a pointer grab. It'll release it when the user clicks outside of the menu region (including on any other window). When running via Xwayland, it'll never receive those outside clicks if the clicks happen outside any X11 window. In the cases of this bug, its most likely that the X11 application expected everything to work just as "good old X11" has always, i.e. that it'll have complete control, but got really confused when that was not the case. The code path in that application that should have dismissed the grab was never trigger, resulting in the grab getting stuck. To fix this, I see three potential strategies: 1) Try to investigate why the application gets its grab stuck, and fix the application to be less greedy and grumpy. This is cumbersome, since there might be many applications that has these issues. Note that this is, as far as I know, the only way to solve these types of issues in pure X11 land. 2) Try to investigate why the application gets its grab stuck, and figure out a way to "emulate" X11 some way to trigger the correct path. This *might* fix more than one application but who knows. 3) See if its possible to introduce some direct hooks from the compositer directly into Xwayland to cancel any grabs. This could be done at strategic places, such as when a Wayland window is focused etc. I don't know whether this is possible, due to some X11 semantics or lack of there of.
I suspect this has to do with drag'n drop. I could reproduce using IntelliJ (as this was mentioned in previous posts multiple times). 1. Run IntelliJ, have some source file open in the editor 2. Select some text 3. Drag the selection outside of IntelliJ onto a Wayland native window That led to various unexpected behaviors, from all the X11 applications becoming unresponsive to mouse clicks (as described in this report), the destination (Wayland native!) gnome-terminal becoming unresponsive to mouse clicks as well, and eventually gnome-shell/mutter segfaulting when closing the IntelliJ window... Xwayland is not responsible for the crash in mutter/gnome-shell and the Wayland native app becoming unresponsive, so I suspect sonething not quite right in the Wayland compositor (mutter) drag'n drop code, maybe?
Created attachment 347407 [details] gnome-shell backtrace The pointer unresponsive issue in either x11 or wayland native, or both, is pretty much reproducible at will using DnD, but the gnome-shell crash that follows is random. Attaching the backtrace I could capture.
Created attachment 347414 [details] [review] xwayland: Release xdnd grabs ASAP We currently wait for the selection being cleared by the drag source, which might not happen on not quite educated clients. This may leave a stuck XDND grab in the compositor side. We can actually do a bit better, and clear the grab if: 1) The focused wayland drag destination emitted wl_drag_offer.finish 2) No wayland window is focused and all pointer buttons are released 3) As usual, whenever the drag source clears the selection data
I can see this as well when using a mix of native wayland and Xwayland applications (including a few of java/swing apps). Unfortunately using Ctrl + Alt + Fx does not always fix the problem. Fedora 25, gnome-shell/mutter 3.22.3, X 1.19.1, weston 1.12.0. FYI DnD in java uses pointer and keyboard grabbing (jdk/src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java that code is shared between linux and solaris) and it expects to get the button release events.
I tried with attachment 347414 [details] [review] and it still blocks pointer events on the destination (wayland native gnome-terminal) window.
FWIW the Java app raises the following exceptions when this occurs: java.lang.NullPointerException at com.intellij.ide.dnd.DnDManagerImpl.updateCurrentEvent(DnDManagerImpl.java:198) at com.intellij.ide.dnd.DnDManagerImpl.access$1300(DnDManagerImpl.java:41) at com.intellij.ide.dnd.DnDManagerImpl$MyDropTargetListener.dragOver(DnDManagerImpl.java:686) at java.awt.dnd.DropTarget.dragOver(DropTarget.java:382) at sun.awt.dnd.SunDropTargetContextPeer.processMotionMessage(SunDropTargetContextPeer.java:475) at sun.awt.X11.XDropTargetContextPeer.processMotionMessage(XDropTargetContextPeer.java:178) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchMotionEvent(SunDropTargetContextPeer.java:824) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:770) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:48) at java.awt.Component.dispatchEventImpl(Component.java:4744) at java.awt.Container.dispatchEventImpl(Container.java:2294) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:4599) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4461) at java.awt.Container.dispatchEventImpl(Container.java:2280) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.awt.EventQueue$4.run(EventQueue.java:729) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:843) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:675) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:391) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) java.lang.NullPointerException at com.intellij.ide.dnd.DnDManagerImpl.updateCurrentEvent(DnDManagerImpl.java:198) at com.intellij.ide.dnd.DnDManagerImpl.access$1300(DnDManagerImpl.java:41) at com.intellij.ide.dnd.DnDManagerImpl$MyDropTargetListener.dragOver(DnDManagerImpl.java:686) at java.awt.dnd.DropTarget.dragOver(DropTarget.java:382) at sun.awt.dnd.SunDropTargetContextPeer.processMotionMessage(SunDropTargetContextPeer.java:475) at sun.awt.X11.XDropTargetContextPeer.processMotionMessage(XDropTargetContextPeer.java:178) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchMotionEvent(SunDropTargetContextPeer.java:824) at sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:770) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:48) at java.awt.Component.dispatchEventImpl(Component.java:4744) at java.awt.Container.dispatchEventImpl(Container.java:2294) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:4599) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4461) at java.awt.Container.dispatchEventImpl(Container.java:2280) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:90) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.awt.EventQueue$4.run(EventQueue.java:729) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:843) at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:675) at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:391) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
I suspect that's a race, because it's random and less likely to happen with attachment 347414 [details] [review], but it still occurs. I can also cause various issues with DnD even among wayland native clients, e.g. configure gedit to show line numbers, select some text in gedit and drop it onto the line numbers column of the same window will cause all keyboard input to stop until the focus is moved to another window - That could be another issue though, but still related to DnD.
One more thing (if tht can help), you don't need a full feature Java application to reproduce, even basic Java examples can exhibit the issue: 1. Run https://docs.oracle.com/javase/tutorial/uiswing/dnd/basicdemo.html 2. "Turn on drag and drop" in the demo (checkbox at the bottom of the window) 3. Select some text in the JTextArea and drop it onto a gedit window (that works with other Wayland apps as well) Actual behavior: gedit becomes unresponsive to mouse clicks until the icedtea window is closed.
How this wasn't found before if it's so easy to block an app?
To investigate and fix issues, we need to have tangible data, either a backtrace or a reliable way to reproduce, until comment 22 we had neither (afaik) and the issue was just stated to be random.
(In reply to Pedro Adame from comment #30) > How this wasn't found before if it's so easy to block an app? This bug is full of uncertainties, It is Olivier who has managed to find 1) a specific set of apps to point to and 2) the actual operation that triggers the misbehavior. The appropriate comment is "thanks", not "why so late".
Created attachment 347478 [details] [review] xwayland: Release xdnd grabs ASAP We currently wait for the selection being cleared by the drag source, which might not happen on not quite educated clients. This may leave a stuck XDND grab in the compositor side. We can actually do a bit better, and clear the grab if: 1) The focused wayland drag destination emitted wl_drag_offer.finish 2) There's no accepting drag destination and all pointer buttons are released. 3) As usual, whenever the drag source clears the selection data
Created attachment 347479 [details] [review] xwayland: Check MetaDndBridge focus_window when updating X11 proxy window We are keeping accounting of the focus window as seen by the DnD bridge right here, so use it instead of the MetaWaylandDragGrab focus as it may lag behind the real focus (i.e. till the drag source notices the window and sends XdndEnter to it). This leads to the window trying to be repositioned more often than necessary when the drag source takes long to send the XdndEnter client message, and maybe not repositioned at all if the pointer leaves the surface while no XdndEnter message was received.
Review of attachment 347478 [details] [review]: Looks good to me and prevents the segfault in mutter reported in comment 23
Review of attachment 347479 [details] [review]: Looks good to me
The two patches fix the issue with Java, but the same still occurs with KDE (sorry...): 1. Run gtk3-demo (gtk3-demo --run=application_demo) 2. Run kate and open some text file 3. Select some text in kate, drop it onto gtk3-demo application demo window Actual result: gtk3-demo won't respond to pointer input until kate gets closed.
Both patches are now pushed to the master branch. They are candidates for backporting though. Attachment 347478 [details] pushed as 21b2eff - xwayland: Release xdnd grabs ASAP Attachment 347479 [details] pushed as 572610d - xwayland: Check MetaDndBridge focus_window when updating X11 proxy window
will these patches solve the problem with KDE programs too?
With the patches, failed DnD from KDE apps won't block the shell, the specific reason why DnD fails with Kate (and I don't know if other KDE apps) requires further investigation.
Thanks. Do we need a new bug report specific for QT programs?
Yes, I don't think there's any, please file a new one.
Here is https://bugzilla.gnome.org/show_bug.cgi?id=779757
Hi, I have a similar bug with QGIS, which use Qt4, and logically xwayland. Does the patches correct also for QGIS or do i have to fill a new bug ?
The fixes should also work for your case, QGIS being a Qt app. IMO better try the fixes first and file another bug if it still doesn't work for you.
I don't know how to update to the latest beacause i'm on Fedora 25. I will stay for updates, i think.
The fixes can be safely backported and I pushed them to the gnome-3-22 branch, they will eventually reach f25, but I can't guarantee when.
(In reply to Olivier Fourdan from comment #29) > One more thing (if tht can help), you don't need a full feature Java > application to reproduce, even basic Java examples can exhibit the issue: > > 1. Run https://docs.oracle.com/javase/tutorial/uiswing/dnd/basicdemo.html > 2. "Turn on drag and drop" in the demo (checkbox at the bottom of the window) > 3. Select some text in the JTextArea and drop it onto a gedit window (that > works with other Wayland apps as well) > > Actual behavior: > > gedit becomes unresponsive to mouse clicks until the icedtea window is > closed. This bug is not present any more, but drag-and-drop is now completely broken from Java apps. Following the same steps will result in no drag-and-drop being possible from Java app to GEdit.
(In reply to Christian Stadelmann from comment #48) > This bug is not present any more, but drag-and-drop is now completely broken > from Java apps. Following the same steps will result in no drag-and-drop > being possible from Java app to GEdit. It works here, just drag out of the window and back and then you can drop - This is a known glitch with Java that is way better that freezing all the apps...
(In reply to Carlos Garnacho from comment #38) > Both patches are now pushed to the master branch. They are candidates for > backporting though. > > Attachment 347478 [details] pushed as 21b2eff - xwayland: Release xdnd grabs > ASAP > Attachment 347479 [details] pushed as 572610d - xwayland: Check > MetaDndBridge focus_window when updating X11 proxy window The fixes were not applied on f25, yet. I don't want to wait any more, so I downloaded mutter-21b2eff.tar.xz, mutter-572610d.tar.xz, and its patches. Then, I tried to use the patch command, but I didn't find the original files. Can anyone help me to install these patches. Thx.
(In reply to Guilherme Ferreira from comment #50) > The fixes were not applied on f25, yet. Yes, enable the updates-testing repository or install https://koji.fedoraproject.org/koji/buildinfo?buildID=878989
(In reply to Guilherme Ferreira from comment #50) > (In reply to Carlos Garnacho from comment #38) > > Both patches are now pushed to the master branch. They are candidates for > > backporting though. > > > > Attachment 347478 [details] pushed as 21b2eff - xwayland: Release xdnd grabs > > ASAP > > Attachment 347479 [details] pushed as 572610d - xwayland: Check > > MetaDndBridge focus_window when updating X11 proxy window > > The fixes were not applied on f25, yet. > > I don't want to wait any more, so I downloaded mutter-21b2eff.tar.xz, > mutter-572610d.tar.xz, and its patches. Then, I tried to use the patch > command, but I didn't find the original files. Can anyone help me to install > these patches. Thx. To stay productive while patches are on their way to your repo you can also select your Gnome session to launch on Xorg instead of Wayland.
I can confirm this issue with GNOME 3.24.3 on Arch Linux. VirtualBox is the application that causes this so far, currently 5.1.28 and older. Unknown if it happens in full-screen mode since only use Window mode. Switching to console and back does not fix this issue when it occurs. Only way to fix the issue is to use the keyboard to gain focus on the guest vm and initiate a shutdown via keyboard request. Once the guest vm window is gone, mouse events start working correctly. Currently use Mouse focus for switching Window focus. Mouse pointer still properly moves around the desktop. Mouse events seem to be sent to limbo where the guest vm nor any other windows are able to process them.
VirtualBox is grabbing the keyboard on X11, so that might play as well, not sure this is the same issue. You may want to try with the patches from bug 783342 along with Xwayland from git master which has the Xwayland grab support.
*** Bug 771037 has been marked as a duplicate of this bug. ***