Bug 107149 - metacity moves windows when no mouse button pressed
Summary: metacity moves windows when no mouse button pressed
Status: CLOSED DUPLICATE of bug 109915
Alias: None
Product: Fedora
Classification: Fedora
Component: metacity   
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
: 112655 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-15 14:05 UTC by Dams
Modified: 2007-11-30 22:10 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:59:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for metacity 2.6.3 (2.36 KB, patch)
2004-04-19 03:15 UTC, Marc Deslauriers
no flags Details | Diff
Patch for RHEL 3 (2.36 KB, patch)
2004-04-28 09:24 UTC, David Juran
no flags Details | Diff

Description Dams 2003-10-15 14:05:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009

Description of problem:
I often use the alt-click1 shortcut to move windows and sometimes when i release
the mouse button the window is still moving along with the mouse. I saw some
strange behaviour like alt-click1 on window1, moving window1, release mouse
button 1, alt-tab to go window2, then moving mouse also move window2 (window1
doesnt move anymore).

I cannot find a good way to reproduce this, but it happens to me maybe 3-4 times
a day. It's very annoying.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See description

Additional info:

Comment 1 Dams 2003-10-15 17:02:17 UTC
Sometimes i single-click on the top bar to raise the window and even after i
released the button1, the window move like the mouse does..

Comment 2 Ralph Loader 2003-10-17 01:40:00 UTC
I'm seeing this too.  It happens most when my system is swapping badly.

Typically I click mouse1 on the title bar to focus and raise the window. 
Metacity acts as if the mouse button is not released.

When swapping lots, it happens about 50% of the time.  When idle, almost never.

Comment 3 Mikael Carneholm 2003-10-24 19:38:21 UTC
Same thing here. I.e, single-click on the top bar of a window, release the
button, and the window is attached to the mouse cursor. Seems like it depends on
how "fast" you click/release the button...?

Comment 4 Russell Inman 2003-10-25 13:02:49 UTC
Same problem, only on a dual-xeon system with 2 GB of ram under normal desktop 

Comment 5 Dams 2003-11-01 18:35:44 UTC
Problem still exists with current rawhide (1st/11/2003) using
metacity(0:2.6.3-1).i386. comment #3 is still valid. It happens when
system briefly hang (because of swap or whatever..).

Comment 6 David Juran 2003-11-05 10:20:57 UTC
I'm seeing this on taroon as well.
A weird observation is that this behaviour described in comment #3
does not happen for a gnome-term but does happen for a xterm.

Comment 7 Pete Zaitcev 2003-11-07 06:05:52 UTC
Same thing as comment #3. The following conditions should be met for
it to happen:
 1. Click into a title bar of a window other than the top window.
 2. Click, e.g. minimal delay between down and up events.
Little green cross appears on the right of the mouse cursor.
This is 100% reproducible. BTW, I use a laptop with built-in
ALPS Glidepad, so it's super easy to create a sharp click
just by tapping. But it's not too hard to click sharp enough
with a button #1.

It would not be so maddening, if there was a way to undo the move.

Comment 8 Pete Zaitcev 2003-11-10 18:59:21 UTC
In my testing, it does not seem to happen on a rebuild off gnome.org,
but reliably happens in FC-1 binary. Trying FC-1 srpm next.

Comment 9 Pete Zaitcev 2003-11-10 20:07:25 UTC
The situation is a little clearer now.


    case ButtonRelease:
      if (display->grab_window == window &&
          event->xany.serial > display->grab_start_serial &&
          grab_op_is_mouse (display->grab_op))
        meta_window_handle_mouse_grab_op_event (window, event);

The serial of the grab can be bigger than the serial of the
button release, if you release fast enough, and so the move
gets stuck.

The offending code is on in the stock 2.6.3. It comes from
the patch metacity-2.5.3-reduced-resources.patch.

Comment 10 David Juran 2003-11-11 14:16:32 UTC
I can indeed verify that backing out patch 5 from metacity-2.4.55-6
(in RHEL 3) remedies the problem. So now for the real solution (-:
Would it be as simple as removing the line or will that have some
nasty side effects? Why is it there in the first place? Is it just
some kind of sanity check?

Comment 11 Havoc Pennington 2003-11-11 23:19:23 UTC
From ChangeLog:

	* src/display.h (struct _MetaDisplay): add grab_start_serial used
	to avoid responding to events that occurred prior to the grab

	Still broken in various ways, specifically EnterNotify that
	occurred prior to XGrabPointer is processed as if it occurred

I'm not exactly sure though why this was done (what the events prior
to the grab were). Also, perhaps it isn't taking into account a
passive grab; if the X server autograbs the mouse when the button
press is done, the grab start serial should probably be the button
press event serial. Not sure that's done at the moment.

Comment 12 Jan Machac 2003-12-31 11:01:15 UTC
*** Bug 112655 has been marked as a duplicate of this bug. ***

Comment 13 Carwyn Edwards 2004-02-25 17:03:30 UTC
FYI this is still in metacity-2.7.0-1 (latest in rawhide as I write).

Note the last specfile changelog entry:

* Wed Feb 25 2004 Alexander Larsson <alexl at redhat.com> 2.7.0-1
- update to 2.7.0
- removed reduced resouces patch (its now upstream)

Comment 14 Gary Mansell 2004-03-18 14:10:29 UTC
I see this also on RHEL 3.0 and it is very annoying - is there
anything that I can do to get around or fix the problem?

Failing this, is there any idea as to when a fixed version of Metacity
will be released through the RHEL update channel?

Comment 15 Elijah Newren 2004-04-15 00:08:38 UTC
Pete: You said that, "serial of the grab can be bigger than the serial
of the button release".  Are you sure that's true?  I just tracked
this bug down today (didn't know about this RedHat bug about it) and
found that the problem for me wasn't that the serial of the grab was
bigger than the serial of the button release but rather that the
serial of the grab *was equal to* the serial of the button release.

Can people test the patch in
http://bugzilla.gnome.org/show_bug.cgi?id=136587 and see if that fixes
the problem for you?  It works for me...

Comment 16 Marc Deslauriers 2004-04-19 03:15:58 UTC
Created attachment 99525 [details]
Patch for metacity 2.6.3

Comment 17 Marc Deslauriers 2004-04-19 03:17:06 UTC
The fix works for me using metacity-2.6.3-1 from Fedora Core 1.

Here is the patch I used on 2.6.3.


Comment 18 Dams 2004-04-26 16:52:31 UTC
Problem still exists with metacity-2.8.0-1

Comment 19 Elijah Newren 2004-04-26 17:01:20 UTC
Dams: 2.8.0 was created from CVS as of March 21st, whereas the fix I
proposed was only applied to CVS on April 15th (and there have been no
releases since the fix).  Could you try the patch on bug 136587 (which
is identical to the one Marc provided here, modulo line numbers) or a
version from CVS?

Comment 20 David Juran 2004-04-28 09:24:09 UTC
Created attachment 99731 [details]
Patch for RHEL 3

I've adapted this patch to work with metacity-2.4.55-6 which is distributed in
RHEL 3. Any chance of seing this in an errata?

Comment 21 Mikko Huhtala 2004-05-05 08:44:04 UTC
The problem seemed to go away by updating FC1 to metacity-2.7.1. Did
that release include a patch for this?

On an updated FC2test3 running metacity-2.8.0-1 the bug is definitely
still there. I hope FC2 will not be released with this bug unfixed.

Comment 22 Dams 2004-05-15 08:29:02 UTC
Still present in metacity(0:2.8.1-2).i386 in latest development tree.
Which should be FC2.

Comment 23 Havoc Pennington 2004-05-17 13:51:07 UTC
Doesn't happen for me in 2.8.1-2, and it used to happen to me before.
Anyone else seeing it in FC2?

Comment 24 Mikko Huhtala 2004-05-17 14:48:30 UTC
It has not happened to me either since 2.8.1-2 on FC2. The RPM
changelog only says 'fix mangled Summary', whatever that may mean. The
update coincided on my machine with the installation of the NVidia
drivers (till then I had just used the XFree ones because of frequent
kernel updates for test releases), but that should not have an effect.
I had the problem on FC1 with NVidia drivers.

Comment 25 Elijah Newren 2004-05-17 23:04:38 UTC
I was able to reproduce this reliably under FC1 or any version of
Metacity between 2.7.x and 2.8.0 when compiling Gnome from CVS.  I
cannot reproduce this under 2.8.1 (I've tried both rapid left-clicks
on titlebars and rapid alt-left-clicks in windows, and I no longer see
unwanted drag operations in either case).

Dams: Can you be very explicit about exactly what you are still
seeing?    If you can do that, I can build you an RPM that has some of
the debugging messages I used when I was trying to track down the
problem myself, and perhaps that will provide us with more information...

Comment 26 Pete Zaitcev 2004-05-19 14:49:07 UTC
Looks like it's gone in 2.8.1-2. But I am still on FC1, so I had to
rebuild it from the SRPM. Looks like Elijah was right about serials.
If Dams is still seing this, it might be someone other than the code
snippet I posted.

Comment 27 Alan Cox 2004-05-21 22:07:54 UTC
I've been seeing it since before FC1. It hasn't happened to me yet
with FC2 and it was regularly occuring with FC1

Comment 28 Elijah Newren 2004-05-21 22:17:49 UTC
Since before FC1?  Then perhaps there is something else weird going on
in addition to what I found, as the bug I found was introduced with
FC1.    Perhaps that's why Dams was able to report that he had seen it
with FC2 when no one else has....

Comment 29 Havoc Pennington 2004-05-25 20:33:21 UTC

*** This bug has been marked as a duplicate of 109915 ***

Comment 30 Red Hat Bugzilla 2006-02-21 18:59:09 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.