GNOME Bugzilla – Bug 757676
Moving window between computer monitors freezes mouse and keyboard events
Last modified: 2016-04-27 16:24:11 UTC
Created attachment 314975 [details] journalctl output On Fedora 23 with GNOME 3.18.1 on Wayland, when I move window of Polari IRC client in Overview from one screen to the other (from one computer screen to another computer screen on the left), GNOME Shell stops responding to keyboard and mouse events (I can still move cursor though). It doesn't freeze, since it shows blinking cursors and it shows new message events etc, but it doesn't respond to keyboard or mouse (and switching to another TTY also doesn't work). It only happens when moving window from one screen to the other - it doesn't occur when moving between different workspaces. Steps to reproduce: 1. Use dual-monitor setup 2. Start Polari app 3. While in overview, move Polari window from primary screen to secondary screen Versions: Up-to-date Fedora 23 with GNOME 3.18.1, mutter-3.18.1-4.fc23.x86_64 and polari-3.18.1-1.fc23.x86_64 I'm also attaching journalctl output but it shows nothing useful prior to SysRq call (that I used to reboot my system).
Now it's happening also with GNOME Terminal, Files and Geary, but not with Emacs, Firefox or Atom. One thing that I've noticed is that mouse cursor stays with "window is being dragged" image.
OK so after another bit of playing with it I think that I know how to reproduce this. It happens with Wayland-enabled applications only (so XWayland are OK) and it happens only with *maximized* applications - that's the reason I couldn't reproduce this with Terminal before - it wasn't maximized. So steps to reproduce are: 1. Use dual-monitor setup 2. Start any GNOME app 3. Maximize it 4. In overview, move its window between screens
I was able to get tracebacks using gdb and remote login. I'm attaching them now.
Created attachment 314982 [details] tracebacks from running gdb on gnome-shell
Yeap, it's reproducible at will indeed using the steps from comment 2. Looks like the grab remains active after even the button release. But this /might/ possibly be as well a bug in gnome-shell rather than mutter, overview and drag'n drop of windows being implemented in gnome-shell.
Olivier, is it expected that Ctrl+Alt+Fx keys can't be used to switch to a terminal after this bug occurs? And is there something we could do to prevent this (i.e. make Ctrl+Alt+Fx shortcut work in case of compositor/higher-layer bug?) Could we perhaps even implement something like Ctrl+Alt+Backspace to restart the whole compositor/session, similarly to X11? It might be a bit off topic, but this is a nice example of how a bug in compositor might render the whole system completely unresponsive, while all the layers below work well.
Still happening with mutter 3.19.3.1.
Created attachment 325082 [details] [review] dnd: cancel the animation on drag actor destruction The events are being fed into the dnd handler even after dropping the window, because the _onAnimationComplete() callback is not called
I confirm that attachment 325082 [details] [review] fixes the issue in my case as well.
Review of attachment 325082 [details] [review]: we have this.actor and this._dragActor and they may or may not be the same object. I'd prefer that we register a different 'destroy' signal handler for this._dragActor to perform the animation complete actions if needed
Created attachment 326091 [details] [review] Cancel drag animation on drag actor destruction
Review of attachment 326091 [details] [review]: ::: js/ui/dnd.js @@ +602,3 @@ + // finish animation if the actor gets destroyed + // during it + this._dragActor.connect('destroy', this._finishAnimation); If dragActor isn't destroyed at the end of the drag though, this may cancel the animation of a completely unrelated drag operation
Created attachment 326546 [details] [review] Cancel drag animation on drag actor destruction v2. disconnect the signal on animation complete
Review of attachment 326546 [details] [review]: I haven't actually tested, but looks mostly good. Some additional nits in the commit message: - Capitalize subject (Cancel ...) - Full sentence in body: (If ..., end with full stop) - Drop the v2 line ::: js/ui/dnd.js @@ +594,3 @@ + // start animation + this._dragActorEaseOut(eventTime, + {time: REVERT_ANIMATION_TIME}); Style nit: missing spaces before/after braces @@ +597,3 @@ + }, + + _dragActorEaseOut: function (eventTime, params) { The function name is a bit vague - there are three tweeners that easeOut dragActor, but you are only replacing one of them. _animateDragEnd() or _doDragEndAnimation() maybe? @@ +602,3 @@ + // finish animation if the actor gets destroyed + // during it + this._dragActorDestroyCbId = We usually use signalName+Id or object+SignalName+Id, by that convention the name would be _dragActorDestroyId @@ +629,2 @@ _onAnimationComplete : function (dragActor, eventTime) { + // disconnect the destoy signal from drag actor Typo: destoy Or just drop the comment altogether, the code is self-explanatory
Created attachment 326659 [details] [review] Cancel drag animation on drag actor destruction
Created attachment 326660 [details] [review] Cancel drag animation on drag actor destruction forget to remove an argument from _finishAnimation call (it now takes none)
Review of attachment 326660 [details] [review]: LGTM