Bug 104262 - no click and drag window movement
no click and drag window movement
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: metacity (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
: Triaged
: 104373 105724 105872 106250 (view as bug list)
Depends On:
Blocks: CambridgeBlocker
  Show dependency treegraph
 
Reported: 2003-09-11 16:26 EDT by Peter Lannigan
Modified: 2007-11-30 17:06 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-25 15:50:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Lannigan 2003-09-11 16:26:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Netscape/7.1

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

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

How reproducible:
Always

Steps to Reproduce:
1.Login with Gnome
2.Click on a window bar and move the mouse
3.Click again to set the window
    

Additional info:

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.
Comment 1 Matt Wilson 2003-09-11 17:08:22 EDT
I can't reproduce this at all.
Comment 2 Peter Lannigan 2003-09-11 17:22:29 EDT
Hmm.  OK furthur testing on my part shows that it is not all applications.

It does happen consistently with
  Netscape 7.1
  OpenOffice-1.0.2-4

Intermitantly with
  Evolution

Never with
  gnome-terminal
  hardware-browser


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...
Comment 3 Havoc Pennington 2003-09-12 00:19:52 EDT
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?)
Comment 4 Thomas J. Baker 2003-10-03 15:29:14 EDT
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
separate bug?
Comment 5 Havoc Pennington 2003-10-04 01:09:00 EDT
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.
Comment 6 Havoc Pennington 2003-10-04 01:12:33 EDT
*** Bug 104373 has been marked as a duplicate of this bug. ***
Comment 7 Havoc Pennington 2003-10-04 01:16:09 EDT
*** Bug 106250 has been marked as a duplicate of this bug. ***
Comment 8 Ralf Ertzinger 2003-10-05 10:43:30 EDT
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
weird.
Comment 9 Jonathan Blandford 2003-10-09 14:15:24 EDT
*** Bug 105872 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Blandford 2003-10-09 14:17:54 EDT
*** Bug 105724 has been marked as a duplicate of this bug. ***
Comment 11 Kreg Steppe 2003-10-09 14:51:50 EDT
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.
Comment 12 Daniel Malmgren 2003-10-30 02:33:46 EST
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!"
Comment 13 Ralf Ertzinger 2003-10-30 08:32:18 EST
I still see this on metacity-2.6.3-1 from RawHide/Fedora.
Comment 14 David Juran 2003-11-05 05:32:22 EST
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
behaviour.
Comment 15 Ralf Ertzinger 2004-01-29 08:46:54 EST
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).
Comment 16 mike bautista 2004-04-08 17:34:35 EDT
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.
Comment 17 Havoc Pennington 2004-05-25 15:50:55 EDT
Should be fixed in Fedora Core 2, and a backport of the fix is
scheduled for the next RHEL 3 update.
Comment 21 Havoc Pennington 2005-04-17 12:29:12 EDT
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.

**********


Comment 22 Kurt Kimber 2005-04-18 13:40:15 EDT
(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
i386 GNU/Linux

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.

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