Bug 107149

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..

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.

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...?

Same problem, only on a dual-xeon system with 2 GB of ram under normal desktop 
loads.

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..).

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.

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.

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.

The situation is a little clearer now.

src/display.c:event_callback():

    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);
      break;

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.

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?

From ChangeLog:

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

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

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.

*** Bug 112655 has been marked as a duplicate of this bug. ***

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)

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?

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...

Created attachment 99525 [details]
Patch for metacity 2.6.3

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.

Marc.

Problem still exists with metacity-2.8.0-1

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?

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?

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.

Still present in metacity(0:2.8.1-2).i386 in latest development tree.
Which should be FC2.

Doesn't happen for me in 2.8.1-2, and it used to happen to me before.
Anyone else seeing it in FC2?

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.

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...

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.

I've been seeing it since before FC1. It hasn't happened to me yet
with FC2 and it was regularly occuring with FC1

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....

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

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.