Bug 109915 - (IT#30272) Application window movement problems
Application window movement problems
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: metacity (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
:
: 107149 129205 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-12 16:43 EST by Matt Ferris
Modified: 2007-11-30 17:06 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-09 23:49:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for this problem. (2.30 KB, patch)
2004-05-25 16:01 EDT, Havoc Pennington
no flags Details | Diff

  None (edit)
Description Matt Ferris 2003-11-12 16:43:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Description of problem:
Ever since I have upgraded from Enterprise Workstation 2.1 to 
3.0, I noticed that there is a strange issue with some application 
windows and moving them around. Terminal windows are fine, but 
if I start VMWare, GIMP, OpenOffice and other apps, and try to  
move them on the desktop, they do not move until I click the left 
mouse again. It's like there is some strange delay and the window 
knows where to go, but there is no outline or movement until I click 
again. Then the window "snaps" to where is should be. I set preferences 
to make the window active when the mouse enters it, I do not raise on 
active and Alt is the key to move. 
I found I could "fix" the problem for all windows for the whole session 
if I just Pull Down on ANY windows options (top left "V" options drop 
down) area. I don't have to select anything from the option, just drop it 
down and it's fixed. If I log out and back in, the problem is back 
until I use any window options drop down again. I found different
graphics 
settings, drivers and resolutions did not change this. I also found this 
only happens in the Metacity/Gnome/Bluecurve environment and not in
KDE at all. 
My current setup is Enterprise Workstation 3.0, Sun 24" color monitor
running 1600x1200, NVIDIA 
Quadro generic driver on a Dell Precision 360. Did not see this with same 
hardware in Workstation 2.1 or RedHat 8.0/9.0. 
 
Any ideas?


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

How reproducible:
Always

Steps to Reproduce:
1.Log into the system (under Metacity/Gnome/Bluecurve)
2.Start gimp (or openoffice)
3.Attempt to move the window by holding down the left mouse to grab
the top border of the window.

Actual Results:  I see nothing move until I click the
left mouse again and the window jumps to where I want it to go.


Expected Results:  The window should move as I move the mouse along.

Additional info:

This is not related to content moves vs. window outline moves
unless the window outline is hidden. Odd that just pulling down on
any window properties (and not selecting anything or selecting something)
fixes all windows for the whole session. Something is getting
"read" or set the first time this happens and this fixes everything.
If you get out and back in, you see the issue again. I have seen this
with anyone we upgraded to Enterprise Workstation 3
Comment 1 David L. Parsley 2003-11-14 16:04:49 EST
I can confirm this bug; I get identical results. ... (minutes pass)
FYI, I just grabbed metacity 2.6.3-1 (Fedora version) and installed
it; works fine.  Definitely a metacity thing.  I noticed it running
'xterm' and trying to move them.
Comment 2 Matt Ferris 2003-11-14 16:26:13 EST
And I can now confirm that the metacity-2.6.3-1 from the Fedora
release fixes this perfectly. Thanks so much for the tip and 
hopefully RedHat will correct this issue in their Enterprise 3
release at some point.
Comment 3 Chris Runge 2003-11-20 09:03:20 EST
note: it appears that the problem is addressed if the reduced
resources patch from the original SRPM is removed 
Comment 4 Pancrazio `ezio' de Mauro 2003-12-12 07:51:18 EST
Will this bug fixed in RHEL 3?
Comment 8 Jason Smith 2004-04-02 09:45:42 EST
What is going on with RedHat support?  Will support for RHEL improve
only after RH9 is EOL'd in a few weeks and they can concentrate on
Enterprise full time?  Here is a bug with a known fix which is almost
4 months old and an update has NOT appeared in RHN yet!  The only way
people suffering from this bug can get it fixed is if they each search
bugzilla, find this bug report and fix it themselves manually.  What
is the purpose of the RedHat Network if this is what people are forced
to do?  I guess it is only for security fixes and not bugs like this!  

Since RedHat does not feel like releasing an update to metacity can
they at least respond to this bug and indicate the best way to fix it?
 Should I take the metacity package from Fedora or rebuild the RHEL3
src rpm with the resources patch removed?
Comment 9 Havoc Pennington 2004-05-25 16:00:32 EDT
A fix for this is scheduled to be in the next RHEL 3 update for sure.
The package is at
ftp://people.redhat.com/hp/testing/metacity-2.4.55-7.1.i386.rpm for
testing

I'll attach the patch.
Comment 10 Havoc Pennington 2004-05-25 16:01:09 EDT
Created attachment 100564 [details]
patch for this problem.
Comment 11 Havoc Pennington 2004-05-25 16:33:31 EDT
*** Bug 107149 has been marked as a duplicate of this bug. ***
Comment 12 David Juran 2004-05-27 08:44:44 EDT
The package in comment 9  works fine (-: 
Is the src rpm availble somewhere? I would need a version for x86_64
as well... 
Comment 13 Havoc Pennington 2004-05-29 00:03:49 EDT
I posted the SRPM also now at
ftp://people.redhat.com/hp/testing/metacity-2.4.55-7.1.src.rpm
Comment 14 Havoc Pennington 2004-08-08 23:06:04 EDT
*** Bug 129205 has been marked as a duplicate of this bug. ***
Comment 15 Havoc Pennington 2004-09-05 11:22:29 EDT
This was not in U3 because a lot of other metacity fixes are in
progress, and the resulting package wasn't fully baked.
The package and patch I posted earlier should still work 
for this issue though. We still need to roll it into an update so 
reopening the bug.





Comment 18 Havoc Pennington 2004-11-09 23:49:11 EST
This is in Update 4.

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