GNOME Bugzilla – Bug 136587
Sometimes title-bar click acts like click and hold
Last modified: 2004-12-22 21:47:04 UTC
When using metacity 2.7.0 and 2.7.1 with either sloppy or mouse focus, if I single-click on an unfocused window to raise it, sometimes it behaves like I'm clicking and holding: the cursor turns into a plus, and the window moves to wherever the mouse goes. Most of the time, it behaves like I'd expect, it simply focuses and raises the window. I'm not able to identify a repeatable sequence of events or timing that causes this bug. Auto-raise is disabled. In operation, it feels like the window "sticks" to the cursor, but only some of the time.
This happens to me a _lot_, but I cannot identify steps to reproduce. I thought I would wait until I could before reporting, but it has been many months and I haven't figured it out. This bug reminds me of bug 108166 (which I don't really understand); they might be related. *shrug*
This happens to me damn near always. It is directly related to the time the mouse button is held down. If I very quickly click and release on the title bar of a currently-not-on-top window, that cursor will grab that window and drag it around. If I spend a bit more time with the mouse button down, I don't see the problem. The same problem exists if I alt-click in the window to raise, instead of title-bar click. The opsys needs to be changed to "all" but I am not entitled to do so.
Oops. Looks like I didn't notice that it was my wife who was logged in, when I posted in this bug last time. With Jeffrey's explanation that it's related to the time the mouse button is held down, I can reproduce pretty reliably (though not 100%; I guess I'm just not fast enough) on my laptop. On my desktop, the mouse must be different because it is exceptionally difficult to get this bug to occur. It seems to me that this might be a gtk bug. I'm going to cc the gtk-bugs alias to get their opinion.
Very unlikely to be a GTK+ bug; it's just bad event handling in metacity of some description.
Okay, with further testing, I found that I can do this with any window--even if it's on top and has focus. I started adding some diagnostics and found that this occurred only when the 'serial' field for the ButtonPress event (i.e. event->xany.serial) equalled that of the 'serial' field for the ButtonRelease event. It seems odd to me that the two could be equal (the button really can't be pressed and released simultaneously), but I guess that's why this appears to be hardward dependent for me and I can only reliably reproduce it on my laptop... Anyway, I made a patch which fixes this issue for me. I will attach it in a minute. Peter, Jeffrey: Can you test this and report if it works for you as well?
Created attachment 26665 [details] [review] Dirt simple patch to fix the problem
Created attachment 26668 [details] [review] Better patch Sorry for the spam. I didn't think to find the original cause of the bug until after I had already submitted the previous patch. (and let me just say that it's a royal pain to track down the change that caused a problem without cvs.gnome.org up.) The change that caused this bug can be seen with 'cvs -q diff -u -D 2003-10-12 -D 2003-10-13'. From that diff, it appears that other lines should also be changed in the same way as my previous patch. So this new patch does that. I checked to see if the patch applied to gnome-2-4, since I first experienced this bug with Fedora 1. It appears that it does not. (The reason that the bug appears in Fedora is that they apparently backported the patch and applied it to their own version of Metacity that they shipped.)
You rule! Please apply asap.
Applied.
*** Bug 142057 has been marked as a duplicate of this bug. ***
*** Bug 127917 has been marked as a duplicate of this bug. ***
*** Bug 130492 has been marked as a duplicate of this bug. ***