From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Description of problem:
The default behaviour for moving a window seems to have changed and I can't
figure out a way to change it back. It used to be (for many versions of RedHat)
that under Gnome you could click and drag with the left mouse button on a window
bar (the top), move the window where you want, and then let go of the window.
Now when you left click nothing happens at first. When you let go the window
starts moving and follows your mouse. When you click again it sets the window.
It makes window placement difficult because it takes a while for all this to
happen; even on my P4 2.4 GHz Dell Optiplex.
This seems like a minor issue, but its driving me nuts and I KNOW my users will
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Login with Gnome
2.Click on a window bar and move the mouse
3.Click again to set the window
My Dell box has an ATi video card in it. My .<files> have been carried forward
for a while from RH 7.3 to RH 8.0 to RH Ent 3 (beta 1). The current RH Ent 3
(beta 1) install was a full install - everything on the CD.
I can't reproduce this at all.
Hmm. OK furthur testing on my part shows that it is not all applications.
It does happen consistently with
With Openoffice I click once to select the window, click again and it starts
following my mouse around until I click once more. Hope this helps...
Are the windows maximized when you click?
Does it matter whether you click-release slowly or quickly? (Perhaps it's a bug
in double-click handling?)
I'm seeing this with metacity-2.6.2-1 on fedora-core (severn2). Clicking on the
title bar of an obscurred windows puts metacity into move window mode. (Cursor
changes to arrow with a plus sign, window moves with mouse). It happens almost
all the time for me but I can't say it happens 100% of the time. Windows are
generally not maximized. Because it's fedora and not rhel, should I open a
I am 90% convinced this is XFree86 or kernel or something rather than metacity.
The fact that it happens in RHEL (2.4.55) and also Fedora (2.6.2) reinforces
that view, since 2.4.55 has few changes from RHL9. Also, I can't reproduce this
problem running any metacity version with the older kernel/X on my system. If
you back down to the RHL9 metacity, does this still happen?
It would be useful to try fooling with X/kernel versions and see if it matters.
Perhaps it depends on the particular hardware even?
One bug for all OS's is fine, no need to create a new one.
*** Bug 104373 has been marked as a duplicate of this bug. ***
*** Bug 106250 has been marked as a duplicate of this bug. ***
While 104373 seems fixed with the latest RawHide metacity (2.6.2-1), 106250 is
still there (rare, hard to reproduce).
I am not entirely convinded that this is a kernel/XFree issue, since I have not
seen anything like this running fluxbox on the very same RawHide, or replacing
metacity with sawfish as the windowmanager under Gnome2. Just metacity behaves
*** Bug 105872 has been marked as a duplicate of this bug. ***
*** Bug 105724 has been marked as a duplicate of this bug. ***
I seem to have this happen with gnome-terminal and Mozilla or Firebird. I do web
development and often switch between them. Like posted above, not always, but
often. (I haven't tried new metacity). No probs in KDE either.
I think this is fixed as of 2.6.3. From NEWS file:
- detect case where we fail to get a pointer grab when the mouse is clicked, to
avoid "this window is stuck to my mouse!"
I still see this on metacity-2.6.3-1 from RawHide/Fedora.
I'm still see this bug on released taroon, so it might be apropriate
to change the prduct.
Also I tested this on RHL 9 and severn yesterday and did not see this
I am still seeing this with the latest Fedora Devel metacity. It is
more bound to happen if the machine is under I/O load (installation of
large RPM packages, anacron run).
I am using gnome on
Red Hat Enterprise Linux WS release 3 (Taroon Update 1)
I see this issue as well. It is very annoying. As is stated
elsewhere, it seems to happen more when the computer is loaded.
It is difficult to reproduce, but I have had it happen to me using
virtually every program, so it is either a window manager thing or
something else, not program related.
Should be fixed in Fedora Core 2, and a backport of the fix is
scheduled for the next RHEL 3 update.
Comment received from Kurt Kimber via email:
Your last comment in bugzilla for Bug 104262 was:
> Should be fixed in Fedora Core 2, and a backport of the fix is
> scheduled for the next RHEL 3 update.
I'm still seeing this bug. We're running RHEL 3 with gnome.
% uname -a
Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686 i3
Here's a potential workaround: I disabled Preferences -> "Keyboard Shortcuts"
for "Move a Window" <alt-F7> (don't know if this step is necessary or not).
Then I right click the titlebar of a misbehaving window and select the "Move"
option; window moves, I place it. After doing this, all windows seem to behave
properly for a time. If problem reappears, I re-execute same workaround.
(In reply to comment #21)
> Comment received from Kurt Kimber via email:
> Your last comment in bugzilla for Bug 104262 was:
> > Should be fixed in Fedora Core 2, and a backport of the fix is
> > scheduled for the next RHEL 3 update.
> I'm still seeing this bug. We're running RHEL 3 with gnome.
> % uname -a
> Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686 i3
> 86 GNU/Linux
> Here's a potential workaround: I disabled Preferences -> "Keyboard Shortcuts"
> for "Move a Window" <alt-F7> (don't know if this step is necessary or not).
> Then I right click the titlebar of a misbehaving window and select the "Move"
> option; window moves, I place it. After doing this, all windows seem to behave
> properly for a time. If problem reappears, I re-execute same workaround.
I'm running this version of RHEL 3 with gnome:
% uname -a
Linux xenon 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005 i686 i686
Symptoms: when I click on window's title bar, this action is intrepretted by
metacity as a "move window" command when it should be interpretted as a "raise
window above other windows" command.
What usually initiates this misbehavior is starting a second session on a
machine (i.e., logging in username/password using the gui login screen). The
gnome session manager gives a warning about doing this since the other session
already has ownership of session configuration files. Once I log in to this
second session, then the misbehaving windows usually starts. I'm guessing some
configuration file gets corrupted.
I'm a newbie to this process, but seems to me like this bug should be reopened.