Bug 140276 - Windows unmoveable sometimes
Windows unmoveable sometimes
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-21 18:50 EST by Carlos Rodrigues
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-01 02:44:37 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)

  None (edit)
Description Carlos Rodrigues 2004-11-21 18:50:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Sometimes, when trying to drag a window, it doesn't move.

I can't reproduce this, but it is very common and easy to spot.

I'm setting the severity to high, because this is frequent enough to
be unnerving.

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


How reproducible:
Sometimes

Steps to Reproduce:
1.open a gnome-terminal
2.try to drag it a couple of times
    

Actual Results:  Sometimes the window doesn't move and some text gets
selected on the gnome-terminal window.

Expected Results:  The window should move every time.

Additional info:
Comment 1 Carlos Rodrigues 2004-11-21 19:42:10 EST
I guess I'm able to reproduce it after all. But it isn't easy to
explain in writing.
This happens when I click on the titlebar and move the mouse at the
same time. If I click and the drag (even if the time between the two
events is really small) it works.
Comment 2 Havoc Pennington 2004-11-21 19:43:28 EST
Never seen or heard of this on FC3. There was an old bug like this
around fc1/RHEL3-ish

Can you give more details:
 - exact metacity and X versions
 - WM config options
 - X drivers
 - are you sure your hardware isn't confused somehow
 - anything else unusual about your setup - hardware, configuration,
   custom install choices, 3rd-parth software
Comment 3 Havoc Pennington 2004-11-21 19:44:16 EST
click and drag will look exactly the same as click-while-moving to
metacity, so I don't think it can be that, though maybe
click-while-moving triggers a race condition and click and drag has
enough pause in there to avoid the race.
Comment 4 Carlos Rodrigues 2004-11-21 20:00:43 EST
This is FC3 with all updates, so it's metacity-2.8.6-2 and
xorg-x11-6.8.1-12.FC3.1.

The configurations are the defaults for metacity. I first noticed this
the first time I logged in as root, just after first boot (before
doing any updates). I was using the "nv" driver then. I'm using the
binary "nvidia" drivers now.

I still have FC2 installed on this box and it doesn't exibit this
behaviour.

Don't know if there is anything else worth mentioning. My system is an
athlon 2400, asus a7v8x (via kt400 motherboard) with a GeForce 4 Ti
4200 AGP-8x.

I've never experienced this before, not even on FC1.
Comment 5 Carlos Rodrigues 2004-11-21 20:09:38 EST
Hmmm, I guess this isn't really a metacity bug. The same thing happens
in KDE.
Comment 6 Havoc Pennington 2004-11-21 21:54:51 EST
It could be the mouse hardware or mouse drivers (in kernel or X), perhaps.

Comment 7 Carlos Rodrigues 2004-11-22 07:08:39 EST
I have a Logitech Wheel Mouse Optical USB, but this also happens when
it is connected via the PS/2 adapter. I've also tried with my sister's
Microsoft Intellimouse USB and the results were the same.

Since my FC2 installation is fully updated (the kernels are similar),
my totally uneducated guess would be X.
Comment 8 Carlos Rodrigues 2004-11-22 07:19:33 EST
I had the Emulate3Buttons option set to "yes" in xorg.conf. Turning it
off made things much better. However, it still seems to happen. I will
need more time before knowing if its still here or it's just me trying
too hard to break it.

But this happening with the Emulate3Buttons option is still a bug.
Comment 9 Carlos Rodrigues 2004-11-22 18:37:49 EST
BTW, this very same thing happens on FC2 with Emulate3Buttons.
Unfortunately I don't have a 2 button mouse here to try this out.
Maybe most people doesn't and so nobody noticed this before...
Comment 10 Mike A. Harris 2004-12-07 04:24:15 EST
Are you using Emulate3Buttons with a 3 or more button mouse?  Or is
it a 2 button mouse?
Comment 11 Carlos Rodrigues 2004-12-07 08:08:50 EST
Its a 3 button mouse + wheel (USB).
Comment 12 Kristian Høgsberg 2005-01-28 13:45:01 EST
Could you try to disable 3 button emulation?  Look for a line like
this in /etc/X11/xorg.conf:

        Option      "Emulate3Buttons" "yes"

and remove it and restart your X server.  The 3 button emulation
introduces a small delay between the mouse click and delivering the
event, which could be what you are seeing.

Thanks
Comment 13 Carlos Rodrigues 2005-01-28 21:51:56 EST
I already did that. It works fine without "Emulate3Buttons".

If this is normal behaviour with "Emulate3Buttons", I guess it can be
closed. I'm not sure, but that option was probably enabled by some
mistake of mine during the installation.
Comment 14 Mike A. Harris 2005-02-01 02:44:37 EST
Emulate3Buttons should not be enabled if you're using a real
3 or more button mouse.  It appears that this is just a misconfigured
X server, and not really a bug.

Setting status to "NOTABUG".
Comment 15 David Balažic 2006-07-26 14:23:13 EDT
This "non-bug" is also reported on upstream :
https://bugs.freedesktop.org/show_bug.cgi?id=1752

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