[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: [Bug 113057] kwallet popup window does not grab focus anymore
From: Mats Ahlgren <ahlgren () mit ! edu>
Date: 2006-07-22 6:06:49
Message-ID: 20060722060649.23130.qmail () ktown ! kde ! org
[Download RAW message or body]
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=113057
------- Additional Comments From ahlgren mit edu 2006-07-22 08:06 -------
I've thought about this for awhile, and have come up with the exact solution we need:
PROBLEM:
This dangerous problem stems from two situations: 1) the user starts typing his \
password without realizing the popup dialog doesn't have focus (the big problem), \
and/or 2) while he's typing his password, another program (e.g. chat client) does \
something which changes window focus, like launching a chat window.
SOLUTION:
Either of these proposals will remedy the problem. I propose a simple solution which \
can be implemented relatively easily, and (alternatively) below that I detail how to \
fix the current system to keep it in line with the original intent of the KDE \
developers.
I've thought very carefully about this, and the following pseudocode takes into \
account very subtle situations. Even minor deviations from what I've written may \
create dangerous loopholes. Please feel free to comment and check my work.
[BEGIN SIMPLE SOLUTION]
All password prompts are unconditionally on top of all other windows, always, no \
matter what.
Pseudocode: "All new password windows start on top. If a change would be made to the \
window stacking order, then instead do the following as an atomic action: make that \
change and put the password window(s) on top while keeping their relative order."
[END SIMPLE SOLUTION]
[BEGIN ELEGANT/FIXED SOLUTION]
WHEN { Requesting-Application requests Password-Prompt }
DO {
-- IF {Requesting-App is in foreground} THEN
-- -- {Spawn the password prompt WITH special window-stacking rules (see below).}
-- ELSE
-- -- {Spawn modified* password prompt WITH same special window-stacking rules.}
}
Note: it is very important that this executes ATOMICally -- i.e. when it executes, it \
must execute COMPLETELY and UNINTERRUPTED by other processes or threads.
* The modified password prompt has no password entry-field, but instead says "The \
program [Requesting-App] needs your password to continue. Click this window to enter \
your password." When you click the window and it become active, the field appears and \
is given focus so you can start typing. If the prompt loses focus, then the prompt \
reverts back to the "Click here" window.
Special Rules for Password Prompt Window Stacking Order:
(1) The Post-It Note Rule: "This prompt behaves like a Post-It note attached to its \
master program. (This is a simple rule, but it has some implications, so I'll give \
some examples to illustrate what I mean: When the program would have focus, instead \
the prompt gets focus. When the program loses focus, the prompt loses focus. When the \
program is hidden, the prompt is hidden. If the password prompt is launched by a \
program hidden behind some windows, the password prompt will spawn above the \
requesting program, but below all those other windows. When the program changes its \
z-order, so does the prompt.)" (2) The First-Things-First Rule: "It is impossible to \
click on or otherwise affect the requesting program until the password has been \
entered or the 'Cancel' button has been pressed; the only effect these clicks should \
have is to bring the Note-and-Application window-complex to the foreground." (3) The \
Don't-Interrupt Rule: "If this prompt has focus, then no program - even the \
requesting program - may usurp focus from it. As a corollary, if any program tries to \
create a new window and the prompt is in the foreground, that new window will instead \
be created below the password prompt's master program." (4) The One-at-a-Time Rule: \
"If the requesting program attempt to launch two password prompts at the same time, \
then put the other one on hold until the first one has resolved."
Reasoning:
1) This is elegant and I think it can be implemented in a snap by using KWin's \
toolbar or whatever functionality. It's also what I think the original intent of the \
password prompts was. However, it might not be necessary. 2) Necessary: This prevents \
the situation where you're clicking in the program's GUI, and the password prompt \
launches, and you didn't realize you clicked after the launch of the prompt giving \
focus back to the program. An alternative to this rule is to implement a 0.5 second \
delay during which changes to window stacking order is frozen, to give the user a \
chance to react. 3) Necessary: This prevents the situation where your email client, \
after taking 10 seconds to load, pops up while you're typing your password to another \
program, and you end up sending your password to a mailing list. 4) This prevents \
unnecessary complications.
[END ELEGANT/FIXED SOLUTION]
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]