Bug 249498

Summary:	KRDC grabs the keys(if grab key was turned on) and prevent entering the unlock password for kwallet
Product:	[Applications] krdc	Reporter:	Rostislav Kandilarov <rkandilarov>
Component:	general	Assignee:	Urs Wolfer <uwolfer>
Status:	RESOLVED DUPLICATE
Severity:	major	CC:	bair.daniel, rafallalik, sgonzalez
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Rostislav Kandilarov 2010-08-30 12:19:04 UTC

Version:           unspecified (using KDE 4.4.5) 
OS:                Linux

If you set "grab keys on" the previous time you use krdc this option is saved for future continuation on a session. This is perfect :)! But.. when you have stored the password for this session in kwallet and you try the next time to open the session and kwallet is not opened it will ask you in a window for the general password. Since the "grab keys" has already been activated you could not write anything in the dialogue window. Perhaps may be the "problem" is more general since krdc grabs all the keys even when sometimes it is not on focus... Unfortunately not pretty sure in which exact conditions it happens... 

Workaround is to simply close the krdc, enter the unlock password and run it again :)...

Reproducible: Always

Steps to Reproduce:
Open new session.
Save the passowrd for it in kwallet.
Set "grab keys" on. 
Exit the session.
Close/lock the default wallet in kwalletmanager.
Open the same krdc session.


Actual Results:  
The kwalletd unlock window appears on the top of the sessions but the keys had allready been grabed by krdc.

Expected Results:  
The kwalletd unlock window appears on the top of the sessions and although the "grab keys" is active for the session one CAN enter the passowrd for kwallet.

OS: Linux (i686) release 2.6.32-24-generic
Compiler: cc

Comment 1 Daniel Bair 2011-02-02 21:45:43 UTC

I can confirm this bug. It is still a problem in KDE 4.5 also.

Comment 2 Rafal Lalik 2011-12-13 14:18:16 UTC

I confirm this bug not only for kwallet but also for entering normal password for remote vnc server.

Comment 3 Urs Wolfer 2012-01-02 19:26:47 UTC

Do you prefer to not save and restore the old state of the keyboard grabbing action? I think that would be the best and easiest solution here.

Comment 4 Daniel Bair 2012-01-02 20:01:24 UTC

I think that would be best, too. Otherwise it is impossible to enter the
password. Unless the restoring the keyboard state can be done after
authentication is done?

-Daniel

On Mon, Jan 2, 2012 at 1:26 PM, Urs Wolfer <uwolfer@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=249498
>
>
> Urs Wolfer <uwolfer@kde.org> changed:
> --- Comment #3 from Urs Wolfer <uwolfer kde org>  2012-01-02 19:26:47 ---
> Do you prefer to not save and restore the old state of the keyboard
> grabbing
> action? I think that would be the best and easiest solution here.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Comment 5 Urs Wolfer 2012-01-02 20:09:06 UTC

As a workaround for the moment:
* close the password dialog
* disable the key grabbing action
* close the (broken) vnc session
* re-open the same session
* the password can be entered now

Comment 6 Salvador I. Gonzalez 2012-01-03 14:27:50 UTC

From a users perspective the optimal solution would be to only grab keys when the *main* krdc window has focus and the currently active tab has the grab keys option set.  When the main window looses focus, the tab changes to a session w/o grab keys or grab keys is deselected krdc should 'ungrab' the keys.

From the developers perspective, just defaulting to not grab keys would be worlds easier to fix.

I'd *love* the top solution but the second is a decent option over the current behavior.

(In reply to comment #3)
> Do you prefer to not save and restore the old state of the keyboard grabbing
> action? I think that would be the best and easiest solution here.

Comment 7 Urs Wolfer 2012-01-04 19:24:50 UTC


*** This bug has been marked as a duplicate of bug 191532 ***