Bug 141267

it's not really a bug, but a feature you want...

I consider it a bug since I could be typing in my password when another window, i.e. an IM session, pops up and my password ends up there by mistake. From a security perspective, it can be dangerous to have other windows interrupt typing a password in.

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

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

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

I agree with comment #2 .. also a "security issue" here

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

When my system starts superkaramba intercept focus of kwallet dialog window. I always should to press Alt+Tab to get focus back on kwallet dialog.

This is definitely a bug. When my desktop is restoring its previous session and the prompt appears, as other applications start they steal focus, one of those happens to be quassel. Loads of fun to type your password, hit enter and realize you just posted it to a public irc channel.

Setting focus stealing prevention to extreme is a possible (but very weak) workaround.

Duplicate of #125724 ?

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

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

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

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

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

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

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

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

In Gnome, the keyring password dialog is integrated with the entire session: it is not a regular window, but a prompt that blacks out the rest of the screen. I like that since it means I cannot accidentally enter my password somewhere else if weird things happen with the focus.

Maybe it'd make sense for KDE to also use that approach?

I can see how that could be an advantage to some people, but it'd be a no-go for me. If something wants me to enter a password

1) I want to be able to let that pend while I finish something else (could be watching a movie)
2) I want to be able to move the dialog, for instance to see who is requesting my password

(In reply to RJVB from comment #21)
> I can see how that could be an advantage to some people, but it'd be a no-go
> for me. If something wants me to enter a password
> 
> 1) I want to be able to let that pend while I finish something else (could
> be watching a movie)
> 2) I want to be able to move the dialog, for instance to see who is
> requesting my password

I think the point here is rather about focus stealing by other applications. If a password dialog pops up and I start typing in it, I don't want other applications to steal the focus.

I had situations in the past when I started two applications by clicking two icons. The first one started fast, and the password dialog popped up, I then started entering by password while the second application finally started, stole the focus with a cursor in a chat window, and me just typing the password in the chat window and hitting enter unnoticed.

A full screen modal dialog prevents that but I'm with your opinion that we should not have this kind of modal full screen dialog. Rather, the password dialog should ensure nothing can steal its focus while the cursor sits in its input field. If I manually unfocus the input field, I don't actually care about what the dialog does, letting it pend in the background, the same as you do: to finish a task or find what is actually requesting the password.

So while the password input field is in focus, the dialog should ensure two things:

1. Not letting some other window steal its focus (maybe this needs support from the window manager)
2. Stay in front (so it doesn't go unnoticed behind other windows popping up shortly after it)

But it should also not grab focus unconditionally. Example: I'm currently typing in an editor or chat application, suddenly a password dialog pops up, grabbing focus, and I would enter a wrong password. In the best case, it would just ask again, in the worst case, it may lock an account or fail an operation you didn't want to fail. So if I am actively typing somewhere currently, the password dialog should not focus itself (or at least not focus the password field) but rather just display on top, maybe with some visual distraction like flashing the taskbar item.

I regularly have the situation where I don't even notice the wallet prompt opening, and then later I wonder why my wifi does not connect. So I would definitely prefer a full-session modal dialog. This is one of the things that IMO Gnome got right. (And generally, everything security-sensitive needs a full-session modal dialog to ensure that applications cannot fake a window that looks exactly the same. That's why these kinds of dialogs are typically full-session modal on other OSes, too.)

Password dialogs aren't FS modal on MSWin nor the Mac OS (except the ones unlocking the screensaver). 

I run self-built frameworks, patched for my convenience (convictions, etc). I'll attach the one I use to ensure kwalletd always pushes its pw dialog to the front.

kwalletd doesn't run with RT priorities so occasionally it takes a while to respond on a swamped system. Thus, it does happen that I enter something unforeseen into the dialog. Preventing that is going to be very hard, but it could be an option to require a modifier to accept the entered text via the Enter/Return key. That should reduce the chances of validating an invalid PW, while still not be as invasive as requiring the mouse to be used. Alternatively, disable the Enter/Return key but support using keyboard-based navigation to activate the accept button.

Created attachment 153715 [details]
kwalletd "make foreground" patch (for 5.60.0)

Ensures that the pw dialog always opens in front.

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