Bug 74487 - Klipper causes mouse buttons to not work as planned and menus to hang
Summary: Klipper causes mouse buttons to not work as planned and menus to hang
Status: RESOLVED WORKSFORME
Alias: None
Product: klipper
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Carsten Pfeiffer
URL:
Keywords:
: 68508 77231 78184 78785 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-07 18:01 UTC by Travis Swicegood
Modified: 2006-05-15 21:06 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Travis Swicegood 2004-02-07 18:01:07 UTC
Version:           Installed with 3.2 (using KDE KDE 3.2.0)
Installed from:    RedHat RPMs
Compiler:          Default Fedora Core 1 (not which compiler that is) 
OS:          Linux

After upgrading the KDE3.2, I had trouble with menus hanging and my mouse buttons not working.  This happened most often when I would click on the Kmenu.  Once I would click on an item it would quite responding.  Hitting Alt on the keyboard would remove the menu and let me start over.

After reading a bug report somewhere, I determined that the problem appeared to be with Klipper.  When I removed Klipper, the problem went away.  

This also seemed to effect context menus - right clicking in Firebird would not always display the proper menu.

I am running Fedora Core 1, and upgraded to KDE3.2 through the Fedora RPMs.  To reproduce this, I just need to add the Klipper applet and clicking my mouse button will start to produce odd results and menus will not function properly.
Comment 1 Arne Schmitz 2004-02-11 11:18:24 UTC
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.
Comment 2 R. Seymour 2004-02-12 23:11:07 UTC
This happens to me as well, I am using 3.2 compiled from source on gentoo.
Comment 3 Lubos Lunak 2004-02-13 16:11:48 UTC
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' )?
Comment 4 R. Seymour 2004-02-13 20:17:11 UTC
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
Comment 5 Mario Juric 2004-02-28 09:55:10 UTC
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.
Comment 6 Mario Juric 2004-02-28 20:31:19 UTC
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.
Comment 7 Lubos Lunak 2004-03-01 19:09:49 UTC
Can anybody reproduce this problem using Qt-3.3?
Comment 8 Lubos Lunak 2004-03-01 19:23:37 UTC
*** Bug 68508 has been marked as a duplicate of this bug. ***
Comment 9 Tommi Tervo 2004-03-11 09:53:08 UTC
*** Bug 77231 has been marked as a duplicate of this bug. ***
Comment 10 Frank Enderle 2004-03-13 08:18:48 UTC
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.
Comment 11 Deoren 2004-03-31 00:33:52 UTC
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.
Comment 12 John Firebaugh 2004-03-31 03:23:17 UTC
*** Bug 78184 has been marked as a duplicate of this bug. ***
Comment 13 Tommi Tervo 2004-03-31 10:19:00 UTC
*** Bug 78785 has been marked as a duplicate of this bug. ***
Comment 14 Chelsea Buchanan & Keith Briscoe 2004-04-05 01:56:17 UTC
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.
Comment 15 Tommi Tervo 2004-04-07 20:30:04 UTC
> ------- 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?
Comment 16 Andras Szigethy 2004-04-08 21:22:17 UTC
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.
Comment 17 Jason Salaz 2004-04-12 23:04:55 UTC
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).
Comment 18 Benjamin M. 2004-04-19 23:41:23 UTC
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.
Comment 19 Tommi Tervo 2004-04-21 21:17:41 UTC
*** Bug 80072 has been marked as a duplicate of this bug. ***
Comment 20 Lubos Lunak 2004-04-23 14:51:08 UTC
Can somebody please give me exact instructions how to reproduce the problem after logging in KDE, with the KDE and Qt versions?
Comment 21 Peter 2004-04-23 17:52:43 UTC
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.
Comment 22 Chelsea Buchanan & Keith Briscoe 2004-04-25 22:45:32 UTC
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.
Comment 23 Chelsea Buchanan & Keith Briscoe 2004-04-25 22:47:21 UTC
s/3.0/3.2/g, sorry.  I meant 3.2.
Comment 24 Lubos Lunak 2004-04-27 17:45:38 UTC
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?
Comment 25 Stefan Lüthje 2004-04-27 17:51:01 UTC
Yes, I have still the problem on debian unstable with KDE 3.2.2.
Comment 26 Erich Vinson 2004-04-28 00:20:44 UTC
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!!!
Comment 27 BlackCat 2004-04-28 02:57:45 UTC
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*
Comment 28 Peter 2004-04-28 03:37:41 UTC
The problem still occurs even when Klipper is not running as an applet. It just doesn't occur as frequently.
Comment 29 BlackCat 2004-04-29 23:34:46 UTC
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...
Comment 30 Jez Humble 2004-05-03 19:57:02 UTC
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.
Comment 31 Lubos Lunak 2004-05-12 13:28:11 UTC
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)?
Comment 32 Arne Schmitz 2004-05-23 20:16:53 UTC
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.
Comment 33 Travis Swicegood 2004-05-24 00:42:06 UTC
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.
Comment 34 Lubos Lunak 2004-05-24 10:12:54 UTC
Arne: There's a similar bug #80072. Are you sure the problem you have is still this bug and not #80072?
Comment 35 Travis Swicegood 2004-05-24 16:14:05 UTC
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.
Comment 36 Lubos Lunak 2004-05-24 16:36:52 UTC
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?
Comment 37 Chelsea Buchanan & Keith Briscoe 2004-05-25 09:17:42 UTC
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.
Comment 38 Tommi Tervo 2004-05-31 12:24:51 UTC
I've not seen this bug a while, using qt-copy + patches from May 20.
Comment 39 Matthew Wood 2004-06-02 03:31:54 UTC
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 40 Lubos Lunak 2004-06-27 14:56:46 UTC
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.

Comment 41 jhsterne 2005-03-09 23:42:42 UTC
I see this problem in Konqueror with Qt-3.3.3, Fedora Core 3, kde-3.3.2-0.1 RPMs.