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: Sometimes Steps to Reproduce: Sometimes I can't switch the window focus using the mouse. The mouse moves. The button clicks. But the window focus does not change. I can only type into 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:
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 exsists. 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.
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 future. There is a thread on the kernel mailing list regarding this starting at http://search.luky.org/linux-kernel.2001/msg02637.html
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'.
Errr.... how is this a mouseconfig issue if it happens under X with a working mouse?
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.
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.
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.