Bug 149576 - Window selection often triggers undesired window movement.
Window selection often triggers undesired 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: Søren Sandmann Pedersen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-23 19:22 EST by Chris Hamilton
Modified: 2014-06-18 05:07 EDT (History)
2 users (show)

See Also:
Fixed In Version: rhel3.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-20 10:34:09 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 Chris Hamilton 2005-02-23 19:22:20 EST
>> 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 
same.

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):
metacity-2.4.55-6

>> 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.2.2 window.
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).
Comment 1 Suzanne Hillman 2005-02-25 09:30:25 EST
Could you try updating to the most recent update and see if this problem still
happens?
Comment 2 Chris Hamilton 2005-02-25 11:44:39 EST
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).
Comment 3 Suzanne Hillman 2005-02-25 11:49:14 EST
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?
Comment 4 Chris Hamilton 2005-02-25 12:03:45 EST
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 
guys....  <grrrr>)
Comment 5 Suzanne Hillman 2005-02-25 13:45:25 EST
Ok. Then please have your IT people do this, because I suspect that
your problem is resolved in U4.
Comment 6 Chris Hamilton 2005-02-26 18:31:17 EST
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 
two weeks).
Comment 7 Suzanne Hillman 2005-02-28 14:20:13 EST
Thank you! Please let us know what the result of the update in regards
to this bug is.
Comment 8 Elijah Newren 2005-10-29 18:05:16 EDT
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.

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