Bug 56411 - Mouse moves, focus gets locked. Click ineffective, alt-tab works.
Summary: Mouse moves, focus gets locked. Click ineffective, alt-tab works.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mouseconfig   
(Show other bugs)
Version: 7.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-16 23:25 UTC by Bryce Nesbitt
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-27 21:02:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bryce Nesbitt 2001-11-16 23:25:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:

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

How reproducible:

Steps to Reproduce:
Sometimes I can't switch the window focus using the mouse.  The mouse
The button clicks.  But the window focus does not change.  I can only type
the current window.  Usually I have to kill X to get back in good shape.

Sometimes I get a partial change of focus in netscape.  I'll clearly click
into a dialog box (the title bar changes), but all characters typed go into
the previous focus (such as the URL bar).

In all cases using ALT-TAB will change the focus.

Actual Results:  Linux should not be as flakey as Windows.

Additional info:

Comment 1 Greg Kurtzer 2001-12-01 00:11:34 UTC
I have had similar issues, but only on my IBM laptop. I can not reproduce the
problem on my desktops/servers. To make it even weirder, it only seems to happen
when I am on battery... I am not a newbie, and it does not make sence to me
either, but I figured I should mention it.

I also tried to use enlightenment as the underlying WM, and still had the issue.
I have als tried telling nautilus not to draw the desktop, and still the problem

The problem can be ellicited by opening two gnome-terminals and placing them
side-by-side. Then moving the mouse between them. At random times (usually one
out of 15-20 or so), the one that should be focused is not, and the only way to
give it focus is to move out of the window and back in, or click the title bar.

This also happened with RadHat 7.1 and Ximian.

Comment 2 Greg Kurtzer 2001-12-31 06:32:13 UTC
I think I have found the problem on my A21P IBM Thinkpad...

It has to do with speedsteping which is present on some laptops to slowdown 
the processor when on battery to minimize power drain. When the laptop is 
plugged in, focus works fine, but when I am on battery I see focus bugs on 
several differnt window managers (Sawfish and KDE for example). Disabling the 
speedstep in BIOS seemed to have solved the problem for me.

I believe this was causing the problem because the gettimeofday C function may 
not be returning the correct time if the CPU has changed speed since boot. 
Focus grabs depending on the WM may be dependant on this (to the best of my 
knowledge). I read something similiar on a KDE list.

There is also a kernel boot option "notsc", but that did not seem to help me. 
Hopefully the kernel will be able to address variable CPU speeds in the near 

There is a thread on the kernel mailing list regarding this starting at 

Comment 3 Brent Fox 2002-10-10 18:16:44 UTC
I have just completed a text mode interface for redhat-config-mouse, which means
that mouseconfig will be deprecated in the next release of Red Hat Linux.  

Therefore, I will not be putting any development time towards fixing mouseconfig
bugs, so I'm closing this as 'wontfix'.

Comment 4 Bryce Nesbitt 2002-10-10 21:57:42 UTC
Errr.... how is this a mouseconfig issue if it happens under X with a working mouse?

Comment 5 Bryce Nesbitt 2002-10-10 21:59:03 UTC
Errr.... how is this a mouseconfig issue if it happens under X with a working mouse?

Comment 6 Brent Fox 2002-10-11 03:32:39 UTC
Sorry, this was originally filed against mouseconfig.  The message attached
above happened when I modified all open mouseconfig bugs, and this report was
affected.  I'm not sure exactly what the problem is that you are seeing. 
Perhaps it's a window manager problem, but perhaps it's an X problem.  

I'm assigning it to X to see if mharris has seen this behavior before.

Comment 7 Mike A. Harris 2002-12-27 19:38:02 UTC
This isn't an X problem.  A window manager problem perhaps, but not an
X problem.  I don't know what window manager is being used, so I'm
reassigning it back to the original component it was filed against.

Comment 8 Brent Fox 2002-12-27 21:02:46 UTC
Sigh.  I don't know what else to do besides close this as 'worksforme'.  We
haven't been able to reproduce this on any of our test machines.  

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