Have you tested this with these different window managers in the same installation? (eg selecting KDE vs Gnome in the sessions menu)

Can you attempt to run the 'xevt' tool and confirm that X is receiving the click events consistently?

Perhaps this weekend.  I'll go with re-installing Debian 6, as that's the lowest level distribution that exhibits the problem, and I'd like to minimize the variables.

I spent the evening trying out Ubuntu 12.04.  Unity did not exhibit the mouse problem after 20-30 minutes of testing, but the software center was crashing so I couldn't install the current edition of Gnome or KDE on it.  As there is also other optional software I need to install, that means 12.04 is a wash for me.

However, the Ubuntu 12.04 Unity-based installer ran fine, though slowly.  You have to wait for the full desktop to finish initializing before you can configure the network.  I impatiently cancelled the installer, then restarted it after configuring the network.  It's too bad I couldn't get Gnome running on it to see if the problem persists and run the xevt testing with it.

Ah well.

Sometime over the next week it'll get done.  I have a functional system in the meantime (Ubuntu 10.04.1) that is still supported, so it's not a very high priority for me right now.  But I will add the xevt testing to my plate.

This may take a little longer than anticipated.

I got a text mode install of Debian 6 done, but it frelled the mouse so bad this time that I couldn't even log in via gdm.  Zero mouse response -- it wouldn't move at all.

So I tried to reinstall Fedora/KDE.  But due to some incompatability of some sort, it had an error overwriting the boot loader, and the system became completely unbootable.

After that I reinstalled Ubuntu 12.04 (which is running now), but did not enable the "download updates" option.  Now the software manager works, though I don't like it (it seems you can only queue up 10 tools at a time to download and install, whereas with the 10.04 version you can happily click as many packages as you want for installation.  But I digress...)

I did get KDE installed, so now I've got an Ubuntu 12.04 installation that works well enough for me to install other software.  Interestingly enough, all the button-enabling and lost-click bugs that the Ubuntu Software Center has under Unity disappear under KDE.  KDE just works.

I was hasty when I said Unity works fine.  It doesn't.  Sub-widgets lose the ability to receive mouse clicks, though the mouse doesn't die entirely as it does with GTK linux installers.  The main menu icons still work, though, so it's kind of a weird behaviour.

But as I'd noted before, KDE "just works."  So it's not an X-server or hardware problem.

When it lets me queue up more software, I'll add Gnome to the download list.

The issue has changed characteristics under Ubuntu 12.04.

Instead of Gnome losing mouse clicks, it starts generating application errors and starts trying to send the error information.  However, apport itself fails, which pretty much sends the process into a loop until you kill it manually.

The key thing is the mouse issue itself seems to have been fixed at some point by someone.  As the Debian install is a little older, it still has the problem.  Either that, or Ubuntu has applied a downstream fix that didn't make it into the Debian packaging.

I'm not willing to re-install Fedora just to test this issue.  I only have two OS partitions on this box, and only one box.  I'm quite content running Ubuntu 12.04 with KDE (I played around with Gnome 3 for about half an hour trying to get the mouse problem to recur, and hated every minute of it.  That UI would be HIDEOUS for programming!)

I'm going to have to cancel this bug report.  Gnome 3 is still unusable under Ubuntu 12.04 due to whatever is crashing and throwing the error reporter into a loop, but it's not demonstrating the mouse problem I had been experiencing in the 10.04.2+ and 11.x series of releases.

Now THIS is interesting.

I updated the system in hopes of resolving the apport crash so  I could test Gnome more thoroughly, and because it was also causing most of the Unity problems.

Along came a kernel update as well.

But once I restarted, the Unity login manager (lightdm) wouldn't respond to the mouse.  So I reconfigured to use kdm.

Whatever killed lightdm also messed with the KDE mouse handling.  I had to go into a safe mode session to reset whatever was wrong, log out, and then log in to a normal KDE session.

Now everything is back to normal.

I can't even BEGIN to guess what a login manager could be doing that would mess with a display manager's mouse handling.

Just FYI.

After sleeping on it, I've decided that the KDE problem I had after the updates was probably due to the system doing a shutdown without logging out of the session properly and leaving some buffer file or variables corrupt/incomplete.

I can't think of any other way that the login manager could have affected the display manager, as my understanding is the X server does a reset/restart during the transition from the login manager to the display manager.

If that's not the case, the issue MAY indicate that the login manager is grabbing mouse focus somewhere, not tracking it properly, but not releasing the mouse event focus when the widgets are terminated.  That can't really happen with APIs like Windows uses for drawing displays, but I'm not sure about X.  If the server doesn't do a full reset during the transition from login to display, it is _possible_ that the no-longer-existing-widget was still being sent the X-events.

By the way, I looked into xev (I could not find an xevt to install), and it tracks the events that are sent to that particular window.  I think the only thing I could have done with it if I could get the problems to occur under 12.04 would be to start a window with xev, then after the mouse clicks get lost, try to click in and to drag or resize the xev window.

I'd originally thought it captured and logged ALL X events, but after reading the description of the utility, I realized X events only propagate to the focus window or widget.

It's no help for the original mouse issue, but the behaviour of the package manager under Unity would indicate that the window code is not properly tracking the mouse position and forwarding the events to the appropriate widget.  I've done a lot of custom widget coding over the years and have run into similar issues with my own code in the past.

Still, I am surprised that no one else has encountered the mouse issues I have, but I've yet to find anyone who finds GTK/Gnome or the latest release of Unity to be anything but stable.

I guess I'm cursed. Or at least my machine is. :)

One other thing that might provide a hint as to the cause of the issue:

Under 10.04.2, I was receiving spurious "low battery" popups for the mouse, even after replacing the batteries not five minutes ago.  With 12.04, KDE reports the model and brand of the mouse device, but also a warning that it couldn't query the mouse status due to an issue with the USB permissions.  Perhaps the lack of access to query the USB device in such a fashion is masking a problem with the code that handles low power conditions.

I am now convinced this is a GTK core issue rather than a general gnome problem.

I just had Rhythmbox running under KDE 3, and was editing the data for a few MP3s.  But after I made my changes, the "Close" button would not respond.  At first I thought it was just the usual delay of the tag updates and that the window would close momentarily, but it didn't.

After over a minute, I realized something HAD to be wrong, and tried clicking Close again.  No response.  Nor could I click on any of the text edit areas to activate them, but I could tab through them.

KDE itself wasn't affected by the problem, so I activated another KDE window and refocused on the GTK-based Rhythmbox window.  Now I was able to click the "Close" button and things were fine afterwards.

Obviously the GAIN/LOSE focus events being sent by X are causing GTK to reset whatever is seizing and ignoring the mouse click events, but I am now absolutely certain the core problem is in GTK itself.

By the way, this also confirms that the X server is still issuing mouse-click events -- the KDE based portions of my desktop were fine.  Apparently whatever is going wrong in the GTK widget stack affects the Gnome 2 and Gnome 3 desktops as well as the running application for some reason.  Perhaps a difference in the fundamental way that KDE and GTK/Gnome implement window focus and mouse event processing.

Someone who is familiar with the code in the affected systems would be far better able to understand the details of what's going wrong.  My own X programming experience predates GTK and Qt rather substantially (Motif era.)

first step to get any response: tell us what version of gtk, x server, input drivers and libXi is on your system.

next step: if this is gtk 3.4, see if putting GDK_CORE_DEVICE_EVENTS=1 in the environment makes things work better

Sorry, but I spent almost a week on this issue already.

I've nuked the Ubuntu 12.04 partition.

I'm reinstalling Fedora/KDE.

I have WORK to do.

Rather than trying to figure out which version of GTK was installed with Ubuntu 12.04 (which you could easily learn from Ubuntu's package lists yourself), here's what I suggest you do:

Check the Ubuntu package logs to see which version was installed with 10.04.1.  That was the last version that worked.

Check which version Ubuntu installed with 10.04.2.  That one and every subsequent version doesn't work.

Now you've got a release and date range for querying your development logs to see what changed between those two releases.  That's where/when the bug was introduced.

Don't waste your time trying to debug the specific releases being produced now; the bug is older than that.  You'd just waste a lot of time digging through changes and code that aren't responsible.

sure, not wasting more time here then

Due to other issues, I ended up re-installing WinXP on the box that has been having these hardware problems.

WinXP demonstrated similar mouse focus and click-loss problems.

So I borrowed and tried another USB mouse, but it had the same issues.  So I borrowed and tried an old-fashioned round-connector mouse, thinking it might by the USB ports or controller causing the problem.

The 9-pin worked.

After much further digging (trying to narrow down which ports were bad or if the controller was going), I determined that it's actually the Logitech device itself that's causing the problem.  Not because of a hardware failure, but because it apparently has had it's firmware flashed with an infection of some kind.

If you plug in a USB mouse other than the Logitech and cold-boot, it will work.  But if you plug in the Logitech in addition, it will stop working.  Similarly, if you boot with the Logitech plugged in, and then switch to the "new" USB mouse, it won't work.  Yet the "new" mouse will work in every USB port just fine so long as the Logitech has not been plugged in since the last time the machine was booted.

This turns out to be the case for WinXP, Ubuntu 12.04 LTS, and Fedora16/Gnome.

I really wish I had the hardware and tools to dig into the current firmware on the Logitech.  The symptoms indicate that it's been *infected* with some sort of virus.  I haven't heard of something this creative from the black hat community since an '80s era IBM mainframe "virus" that infected "smart" disk and tape devices such that you had to replace all devices at once, or the virus would just replicate from the old devices to the replacements.  (It was apparently a rather "cute" virus that would ask for cookies, milk, etc.  Type in the word it asked for at the console and the system would resume operations.  But it was so hard and expensive to get rid of that some sites just told the operators to "give" the computer what it wanted by typing in the requested words.)

My apologies to the GTK team.  I was (obviously) thoroughly convinced it was a GTK issue.