Re: [dev] [bug] slock gets red before submitting pass

From: David Phillips <>
Date: Thu, 28 Jan 2016 11:26:48 +1300

On Wed, Jan 27, 2016 at 05:16:55PM +0100, FRIGN wrote:
> On Wed, 27 Jan 2016 13:58:56 -0200
> Brad Luther <> wrote:
> Hey Brad,
> > I think I found a bug on slock.
> No this is not a bug.
> > If you're typing your password and gets a char wrong, you go and
> > delete the char, then continue to type the pass and 'enter' to unlock
> > the screen. All good, screen is blue all the time.
> > Unless... you get the first char wrong. If you mistype the first char
> > of your password and 'backspace' to delete it, the screen goes red
> > even though you didn't 'enter' the wrong password.
> The wanted behaviour is that if somebody touches your computer and types
> anything on the computer, the screen has to be either red or blue.
> red indicating a typing attempt of wrong pw and blue meaning that
> currently something is being entered.
> When you remove a character from a password string, which is not the
> last, slock thinks you are still in editing mode (which is true) so
> it shows blue.
> Now, if you remove the last char, for slock you are like the evil
> coworker typing something in but then thinking: shit, there he is
> coming! quick, remove the entry.
> It's all a security measure so you can see when you go back to your
> computer that someone fucked with it.
> Cheers
> --
> FRIGN <>
Hi all,

FRIGN is right, there is an underlying motive for this behaviour. Perhaps
it could/should be documented somewhere, I don't know.

You have reminded me, however, that one regret I have since implementing
this behaviour is that pressing a modifier key (especially the shift key)
will turn the screen red, since a keypress has occurred and the password
buffer is empty.

But yes, the failure colour on the screen after emptying the password buffer
is desired behaviour for sure.


Received on Wed Jan 27 2016 - 23:26:48 CET

This archive was generated by hypermail 2.3.0 : Wed Jan 27 2016 - 23:36:10 CET