Red Hat Bugzilla – Bug 149576
Window selection often triggers undesired window movement.
Last modified: 2014-06-18 05:07:44 EDT
>> Description of problem:
When I left-click on the titlebar of a window to raise it to the
foreground, the window comes forward, but subsequently follows mouse
movements, as though I am left-click-dragging (which I'm not).
Happens *all* of the time. Sometimes (particularly if I'm moving the
cursor quickly), I see the behavior only after I've moved the cursor
completely *outside* the target window, then as I move the cursor
back over the window, the window snaps abruptly to the cursor at the
original click location. But most of the time, I see the behavior
immediately. It does not matter whether the window is in the
foreground or not before I click the titlebar. The behavior is the
I can usually avoid the problem if I move the mouse very, very
slowly, then keep it as still as possible after clicking on the title
bar. It's as if I have to try not to "startle" the window. If my
stealth is sufficient, the window will come to the foreground and
will not follow subsequent mouse movements. With some windows, no
matter how stealthy I am, the sticking behavior can't be avoided.
For example, if I have two xterms open on the same desktop, I'm able
to avoid the sticking behavior if I take great care and move slowly.
If I have a single xterm, on the other hand, no amount of stealth can
avoid the problem.
(Note that there is a similar problem with moving the window when you
actually WANT to move it---If I click-drag on the titlebar, the
window does NOT immediately follow the mouse cursor, but only begins
to move when the mouse cursor actually leaves the FRAME of the
original window location-- and then, only if the cursor leaves the
frame within the first 1/2-second. If I move the mouse fast enough
to escape the frame before the first 1/2-second, the window will stay
in its original location indefinitely, until I move the cursor *back*
into the frame, at which point the window will snap to my cursor and
follow it to the new location.)
>> Version-Release number of selected component (if applicable):
>> How reproducible:
Nearly 100% of the time.
>> Steps to Reproduce:
1. Single-click on a window's titlebar with the left mouse button(and
release the mouse button). I can reproduce with a gnome-terminal-
2. Quickly move the cursor away from the window.
3. The window is stuck to the mouse cursor, as if you are holding
CTRL (or ALT, depending on your config).
4. Left-click again to drop the window.
>> Actual results:
Window sticks to cursor.
>> Expected results:
Window should stay where it is.
>> Additional info:
I realize this has been seen before, but I couldn't get a clear
picture of whether this bug has actually been fixed or not, and I
could not add updates/questions to the existing bugs (bugzilla was
offended by my attempts).
In particular, bug 104262 seems to describe the same problem.
I'm running RHEL WS 3 (Taroon Update 3).
Could you try updating to the most recent update and see if this problem still
I wish I could-- This is a company box, and our IT guys won't give us
root. So the only way I can try a newer version is to build it from
scratch. I may be wrong, but I think that means I'd need to build
gtk-2.2 (now gtk-2.8, actually), which is a pretty huge undertaking.
I can't justify the time.
If this is a known bug in the version of metacity/gnome I'm using, I
can ask our IT guys to put the updates in the queue for the next
upgrade/shutdown (assuming there are pre-built packages available).
Actually, I may have been confusing. I meant 'the most recent updates
for RHEL3', not 'the most recent version of the package'. RHEL3 U4 is
out, and you're using RHEL3 U3.
Is this something you can do, or have your IT guys do?
If you need root access to upgrade from U3 to U4, then only our IT
guys can do it. Sadly. (I could administer circles around our IT
Ok. Then please have your IT people do this, because I suspect that
your problem is resolved in U4.
I've submitted a request to update to U4, and will update this bug
report after that update has taken place (should be within the next
Thank you! Please let us know what the result of the update in regards
to this bug is.
FWIW, this is a duplicate of bug 109915; this issue was fixed upstream as
#136587 on gnome bugzilla (in Metacity 2.8.1) and backported to U4 of RHEL3
according to bug 109915.