Version: v0.9.5 (using KDE 3.1.93 (3.2 beta 1), compiled sources) Compiler: gcc version 3.3.2 (Debian) OS: Linux (i686) release 2.6.0-test9 klipper freezes on selecting an action (I've tried with html and 'open in konqueror' action). There's no activity whatsoever, even kde looks frozen. On pressing <ctrl>+<alt>, it comes out of the frozen state and performs the selected action. I found this by accident while attempting to switch to a console.
You don't have to select any action. It freezes even without it. It's probably kwin bug. Klipper gets focus but will not give it back. Alt+TAB for example makes it work again.
I think this is the same bug: several times klipper does not take any mouse event. If I click over an action, I have to go down with keyboard, hiting esc or enter on "cancel". And them it opens the URL...
*** Bug 69148 has been marked as a duplicate of this bug. ***
Yep, this bug is still in beta2 (kde 3.1.94). This bug is really annoying, because it doesn't happen always and when it happens it freezes kicker and all kde apps (kwin issue?). When you press esc or alt+tab you get back to work.
More information: this seems to only happen when Klipper is activated via a keyboard shortcut (Ctrl-Alt-R). Has anyone experienced this problem via the automatic pop-up? It seems like something is getting muddled up about what modifier keys are being held down.
> Has anyone experienced this problem via the automatic pop-up? Here on Beta 2 it also happens without touching the keyboard. Just put your keyboard aside and repeat (Copy URL, choose 'open in konq', erase klipper history, Copy url, etc) a few times and you will see.
The klipper freeze happens less frequently in RC1, but it still happens.
Bug 68508 seems to be similar to this one. I experience both bugs since I updated from kde 3.1.5 (Suse 9 rpms) to 3.2 (official rpms)
Likewise
In 3.2.2 I still notice it stalling, but less frequently then it used to.
I can confirm it also happens when invoking Klipper's menu with the mouse. This is the most annoying bug ever! Sometimes only the mouse becomes unresponsive (the pointer moves but it doesn't pass clicks) so I can still navigate Klipper's menu with the keyboard and/or close it with Esc. Most of the times the hang times out anyway, so after a few seconds I can operate Klipper's menu as if it weren't locked. In the somewhat-rare event of a full hang (the mouse moves, but neither clicks nor keypresses do anything, including global Kde shortcuts, and the lock doesn't time out) I have to switch to another VT and kill Klipper, or sometimes even kill+restart kwin. I'm using the system tray Klipper from Debian's KDE 3.2.2-1
Can you still reproduce this problem with KDE3.3?
On Friday 12 November 2004 12:44, Lubos Lunak wrote: > Can you still reproduce this problem with KDE3.3? It's not happened to me (running KDE CVS) in a few months now.
It's not happening here with kde 3.3.1 in Conectiva Linux Snapshot.
Can anyone still reproduce this bug? Otherwise I'll be closing it.
Yea, go ahead and close it. I'm now running CVS, use klipper all the time, and haven't noticed it happening.
Great, will do. Thanks!