Bug 37838

Summary:	first key eaten by screen lock
Product:	[Unmaintained] kscreensaver	Reporter:	ebo
Component:	general	Assignee:	kscreensaver bugs tracking <kscreensaver-bugs-null>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	cshobe, jesus.guerrero.botella, kde.org, kde, rct+bugs
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Other
Latest Commit:		Version Fixed In:	4.6
Sentry Crash Report:

Description ebo 2002-02-05 06:18:47 UTC

(*** This bug was imported into bugs.kde.org ***)


Synopsis:

  unlocking the screen always fails on the first try.

Diagnosis and possible fix:

  Playing around a bit I found that the problem stems from the first key
being eaten before it gets entered as part of the password to the dialog
box.  The probable fix would be to replace a getkey with a peek in the
lock screen code that deals with the event handling.  This will allow
the dialog box to go go to sleep and disappear then on typing the first
character wake up but still allow the password authentication to have it
too.

Workaround:

  type the shift key to wake up the password dialog then enter as normal

  EBo --

Comment 1 Daniel Naber 2002-09-29 21:19:10 UTC

I don't consider this a bug so I set it to wishlist: it should be quite 
obvious that the password is only accepted when there's actually a password 
dialog.

Comment 2 Chris Howells 2004-01-13 10:14:16 UTC

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

Comment 3 wy2lam 2004-03-06 07:02:49 UTC

If you say that "it is obvious that the password is only accepted when there's actually a password dialog", it is also obvious that the first key pressed should be passed along to the password dialog if the character can be in a password.

So if the shift key is pressed or the mouse is moved, the dialog is simply popped up.  However, if I press the space bar or press a "passwordable" character, the dialog should pop up WITH that character already keyed in.

XScreensaver implements this behavior, and I find it more intuitive than KScreensaver.

Comment 4 Casey Allen Shobe 2004-04-15 12:08:21 UTC

I agree completely.  This even used to be the way kscreensaver used to act a long time ago IIRC, and it's a very irritating change that I hate and can't get used to.  It reminds me of having to press ctrl-alt-del on windows just to get to the stupid text input.  I consider this to be a serious usability issue, not a "wishlist" item.

Comment 5 Oswald Buddenhagen 2007-04-11 20:12:07 UTC

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

Comment 6 Con Kolivas 2008-01-05 03:56:47 UTC

The lag between moving the mouse or doing anything and the dialogue box even accepting typing input is also problematic. It would be nice for it to instantly start accepting typing in the buffer before it is visible on the first try, or after a passowrd failure.

Comment 7 Dennis Jansen 2008-08-14 19:12:12 UTC

We could also accept the password without even showing the dialog. That would be nice to confuse people trying to get into your system without permission.

Comment 8 Oswald Buddenhagen 2010-07-06 20:21:01 UTC

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

Comment 9 Oswald Buddenhagen 2010-10-25 09:41:35 UTC

SVN commit 1189445 by ossi:

queue up keypresses

now you can immediately start typing your password without making the
dialog pop up first and then waiting until it has actually done so.

FEATURE: 37838
FIXED-IN: 4.6

 M  +49 -10    lockprocess.cc  
 M  +3 -0      lockprocess.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1189445

Comment 10 Oswald Buddenhagen 2010-12-02 11:31:15 UTC

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