Bug 74487

I have similar problems. Sometimes Klipper wants to invoke the action menu (for an URL e.g.) and does so. In doing this, it also grabs the mouse and then sometimes just hangs. I cannot click anything (because of the mouse grab), but I can use the keyboard to shut down the session.

This happens to me as well, I am using 3.2 compiled from source on gentoo.

Which Qt version do you use? Does the same problem happen also if you run Klipper standalone (i.e. not as Kicker applet, but in systray)? If you remove the applet and re-add it, does the problem happen immediately, or only after Kicker restart (i.e. KDE logout or 'dcop kicker Panel restart' )?

Very interesting, I am using qt 3.2.3, and it seems that with klipper in the systray instead of as an applet the problem disappears.  Honestly, this is good enough for me.  Thanks.  When I restarted klipper as an applet, the problem did not appear immediately, I will post more if I see any strange behavior

I can confirm the problem on a Fedora Core 1 system, using FC1 binary RPMs. Removing klipper applet makes it go away. The behavior was extremely frustrating, as the panel is one of the most klicked areas.

Some additional information:

- when klipper aplet is removed and then readded to the panel, the problem disappears

- when the panel is restarted ('dcop kicker Panel restart') with the klipper applet active, the problem _reappeares_

- the problem is not present when klipper is run as an application in the systray, instead of klipper applet

- the problem does not show up when the panel is restarted without klipper applet, and the applet is then added to an already running panel

Summary: the problem (at least on my computer) only shows up when the panel is started with klipper applet added. Unfortunately, as this is the default for KDE 3.2 setups, it's really, really, really frustrating when you have no clue that it's klipper that's causing it...

PS: If there's anything else I can do to track down this bug, please let me know.

Can anybody reproduce this problem using Qt-3.3?

*** Bug 68508 has been marked as a duplicate of this bug. ***

*** Bug 77231 has been marked as a duplicate of this bug. ***

I can also confirm this bug for KDE 3.2.1 / QT 3.2.3 using the contributed slackware 9.1 packages from the download area. This bug really anoyed me so I was glad to read that just removing klipper as an applet helps. I startet it now from the start menu and the problem went away since klipper not runs as applet but in the taskbar right beside the clock.

Ditto.  Compiled source rpms that were made available here: http://download.kde.org/download.php?url=stable/3.2.1/RedHat/Fedora/i386/

QT 3.2.3 was used during the compilation process, and QT 3.3 was installed (once rpm was compiled during said process) later.

*** Bug 78184 has been marked as a duplicate of this bug. ***

*** Bug 78785 has been marked as a duplicate of this bug. ***

I'm having the same problems here and also have no idea how to remove the Klipper applet from the panel.  Does anyone have any suggestions?  "ps" doesn't show any klipper process I can kill.  The "Configure Klipper..." screen shows no option to turn it off.

Also--it appears that when no mouse clicks are registering anymore, you can press the modifier key (usually Alt) and the mouse suddenly works again.  This is much better than restarting X!  This can also be exciting because all of your queued-up non-working mouse clicks all execute at once.

> ------- Additional Comment #7 From Lubos Lunak 2004-03-01 19:09 ------- 
> Can anybody reproduce this problem using Qt-3.3? 

Yes, using 3.3.1 from qt-copy + bunch of patches. How can I debug clipper, it won't start under gdb?

I installed Fedora Core 1, updated all the Fedora packages, updated to KDE 3.2.1 with QT 3.3.1, and this bug made me crazy for a week and I did not want to believe that a new Fedora + KDE install can freeze like this :) Then I found this page luckily. Huh.

I will have to agree with Andras.  I'm glad that I found this issue, because I did the same thing that Andras did. Upgrade Fedora RPM's and all (imagine that over a dialup connect, ugh).

I think I am seeing this bug (Slackware 9.1, KDE 3.2.1, QT 3.3.1, XFree 4).  However, I am not using Klipper as an applet.  It is in the system tray, and was manually run.

*** Bug 80072 has been marked as a duplicate of this bug. ***

Can somebody please give me exact instructions how to reproduce the problem after logging in KDE, with the KDE and Qt versions?

I'm not sure if there are exact instructions. The problem occurs intermittently when clicking on the Klipper icon and trying to select a clipboard item from the popup menu. Mouse clicks become captured no matter where you click, even in another application, but they aren't processed so they end up in a queue. Hitting Esc releases the queued up clicks. One or more sequences of click-Esc clears the problem for a period of time, then happens again. It occurs whether Klipper is running as an applet or as a task tray application but significantly more frequently when running as an applet.

I'm using KDE 3.2.1 and Qt 3.3.1.  It's a standard Fedora Core 1 machines upgraded with KDE RPMs, nothing special.

As the previous commenter noted, this is not a reliably reproducable bug.  To reproduce on my machine: click the "K" button over and over, at changing increments (never more than a second).  Eventually, the "K" menu will come out and won't go away.  Once that's happened, all mouse clicks (including mouse clicks not on the Kicker) are disabled.  Mouse clicks also stop working in GTK applications.  The easiest way to restore normal behavior is to hit the Alt key, and everything comes back.

I know my opinion is just my opinion, but I think this has been the most severe bug in KDE since the 3.0 release.  KDE has been freezing up multiple times per day since I upgraded to 3.0.

s/3.0/3.2/g, sorry.  I meant 3.2.

I've been told by one person on IRC that the problem can be no longer reproduced with KDE3.2.2. Does anybody still have the problem with KDE3.2.2?

Yes, I have still the problem on debian unstable with KDE 3.2.2.

Yup, I still have the issue on KDE 3.2.2 on Fedora Core 1. And I have to say, was I glad when I found this bug! I was pulling my hair out!!!

BYE BYE APPLET!  Wow, that is one painful bug.  It is well worth the 50 seconds to fix this problem because it is far too annoying to ignore.

The exact steps for the workaround are:

1. Right click on the bottom panel in some empty gray space.

2. Highlight "remove" and then "applet".  You should see Klipper there.  CLICK IT!
Klipper apparently won't go down easy, so you will likely freeze your desktop at least twice trying this.  Hit Alt-ESC or ESC or whatever to unfreeze it and try again.  

3. From the big K, go to Utilities and run Klipper.  It'll come back to where it was before but NOW it isn't running as an applet.  The problem is GONE.  *Wheh*

The problem still occurs even when Klipper is not running as an applet. It just doesn't occur as frequently.

I haven't seen it since removing it as an applet/running as application on Fedora Core I, KDE 3.2.2.  And I had the bug BAD as an applet...

I was having problems using alt + tab - in kde 3.1.5 (debian testing) it would occasionally stick (i.e. releasing 'alt' would not cause the window to disappear) and I would have to click elsewhere to unstick it. In kde 3.2.2 (debian testing) I had the same problem - but clicking the mouse had no effect, even though kde was still responding (e.g. mouse pointer changed shape in appropriate places on the screen etc). The only way to solve the problem was to ssh in and kill kdm. Yuk. Then I found out about this klipper business - and indeed, removing klipper from the taskbar solves the problem.

I could reproduce the problem very easily using alt + tab - it would happen every 5 / 6 times I tried doing it.

Can anybody reproduce the problem with either Qt-3.3.2 or with older Qt version where you definitely know it had qt-copy patch 0034 applied (for bug #61412)?

Yup, definite-fu**ing-ly yes! I have installed Qt 3.3.2 and rebooted the whole box, just to be sure. Klipper still hangs sometimes. And with it the (KDE) application I am using at that time.

Just a note, after a recent fresh install of Fedora Core 2, this bug appears to have disappeared.  I haven't run Klipper very much, but when I did it doesn't misbehave.

Arne: There's a similar bug #80072. Are you sure the problem you have is still this bug and not #80072?

No, it sounds like that bug might be a duplicate of this one though.  The same general thing happened, but stopped as soon as Klipper was disabled.  The hanging of menus is unique though.

No, that's not a duplicate just because they're both about klipper and freezing. #80072 happens only immediately after selecting some text in a running application.

So, can anybody still reproduce _this_ bug with qt-3.3.2?

I can't reproduce this with 3.3.2.  However, I stopped being able to reproduce it with 3.3.1 also, and there have been no system changes at all from when I could.  This is a horribly unreliable bug to reproduce for those who have encountered it.  I suppose given enough time without reproducing the bug, we can assume it's fixed.  It used to happen very frequently to me.

I've not seen this bug a while, using qt-copy + patches from May 20.

I recently installed Fedora Core 2 which comes with kde 3.2.2 and qt 3.3.2.  I immediately noticed that when using the KDE environment the mouse would often become unresponsive -- usually when I was trying to highlight some text in the address bar of my browser.  The same behavior never appeared in GNOME.  Since finding this thread I disabled the klipper tool and voila no more hanging.

Comment #39 is bug #80072, which is something different (technically, at least). And since nobody can confirm this bug with Qt-3.3.2+, I consider this problem fixed in that Qt version.

I see this problem in Konqueror with Qt-3.3.3, Fedora Core 3, kde-3.3.2-0.1 RPMs.