GNOME Bugzilla – Bug 736690
click to main window toolbar sometimes causes sticky window move
Last modified: 2018-05-02 16:15:12 UTC
There is a race condition in the implementation of the "drag and move window" that causes sticky window move even after mouse button release. evolution-3.12.5 XFCE-4.10 openSUSE-13.2 Factory snapshot x86_64 mouse pointer mode: move mouse to get focus, click to get window to front How to reproduce: Work for half of an hour in another application and then click and instantly release button to get Evolution window to front. What actually happens: Evolution windows is in move mode, even if my mouse button is released. What I expect to happen: Exit move mode in a moment of mouse button release. How often it happens? When I am trying to reproduce, I will nearly always fail. But if I will work for half of an hour in another application and then click to Evolution window to get it to front, it happens in about 50% of cases.
If Evolution is started by gtk-dilatory debug tool, the problem is much easier to reproduce: ftp://ftp.suse.com/pub/people/sbrabec/gtk-dilatory/index.html
Window movement is of course handled by GTK+ and your window manager. This doesn't strike me as a bug in the Evolution code.
You are right. Drag-anywhere-and-move is a generic GTK+ feature. However I seen this bad behavior only in Evolution during daily use. But in gtk-dilatory, I am able to reproduce this problem in other GTK+ applications as well, for example gucharmap-3.12.1. I am using gtk+-3.12.2 and xfwm-4.10.1. It seems to be a problem of race inside gtk+: gdk_x11_window_begin_move_drag() -> (gdk)emulate_move_drag() -> create_moveresize_window() It seems that gdk_device_grab() can be called after button release, so the window will stick in GDK_POINTER_MOTION_MASK and will not get GDK_BUTTON_RELEASE_MASK. One has to click-and-release to leave this state.
I see this with Emacs all the time. Steps to reproduce: 1. Have an Emacs window in the background, another window in the foreground. 2. Single-click on the titlebar of the Emacs window in the background. 3. Emacs window is now in sticky move mode. Arch Linux x64, gtk3+ 3.14.7
Ulrich Keller: Yes, the problem is reproducible in all gtk3 applications in window managers not implementing _NET_WM_MOVERESIZE and on devices with touchscreen (i. e. if _should_perform_ewmh_drag() returns false).
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
It is still reproducible in all GTK+3 applications using gtk+-3.22.26 in XFCE 4.12.
Reopening.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/508.