Red Hat Bugzilla – Bug 109915
Application window movement problems
Last modified: 2007-11-30 17:06:59 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
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.
Version-Release number of selected component (if applicable):
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.
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
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.
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.
note: it appears that the problem is addressed if the reduced
resources patch from the original SRPM is removed
Will this bug fixed in RHEL 3?
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?
A fix for this is scheduled to be in the next RHEL 3 update for sure.
The package is at
I'll attach the patch.
Created attachment 100564 [details]
patch for this problem.
*** Bug 107149 has been marked as a duplicate of this bug. ***
The package in comment 9 works fine (-:
Is the src rpm availble somewhere? I would need a version for x86_64
I posted the SRPM also now at
*** Bug 129205 has been marked as a duplicate of this bug. ***
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.
This is in Update 4.