Version: (using KDE 4.2.0) OS: Linux Installed from: Debian testing/unstable Packages Password windows should have focus. That's OK. But it is not OK that a new password window can appear and steal focus while I'm typing another password. This way, one mail server can get the password I have in another server. The problem is that POP (and IMAP) password windows appear and steal focus in the moment in which the computer receives server's login question, and for the second server this can be while user is typing the password for the first one. Thus, the first server's password window gets only the few first characters (maybe none) and the second server's password window gets the remaining characters and [ENTER], causing, in the better case, an Invalid Login answer and, in the worst, that the user's first server password leaks in the second one. The better solution is, IMHO, that password windows appear without focus if the currently focused window is a password window too, and better if high enough in the focus pile to be the next window receiving it when the user presses ENTER.
Please check the following configuration in you system settings, in window behaviour, if you have the "Focus Stealing prevention mode" to Normal, High or Extreme, and if this happens to you in those cases.
Hola Jaime: I'm sorry, but I can not check that. KDE 4.2 is so buggy that I removed it and returned to 3.5.9 which is (almost) stable and useable. I have the .kde4 directory still around here, so if I can check it there, I will do. It is the Debian standard config (I did not touch focus and related settings). Un saludo Noel Torres
I have the same problem, but with non-password windows stealing focus from password ones too (e.g. a text editor opening on startup as I'm entering the kwallet password). I don't think "focus stealing prevention mode" does the right thing — in my testing all it did was stop some windows taking keyboard focus however they're used (on high mode it even stops the KDE menu taking focus when launched with Alt+F1, which is almost certainly wrong since a user action triggered the menu). The fix *I'd* like to see is the following: 1) If keyboard input occurred in the last 500-1000ms and the window recieving the input is still active, don't let another window steal focus. Alternately, let the new window gain focus but block keyboard input for a few ms. 2) If keyboard input occurs in the first 100-200ms of a new window taking focus for some reason other than the user clicking on it, block the input. Alternately when a new window pops up, don't switch focus until a few ms later.
Duplicate of https://bugs.kde.org/show_bug.cgi?id=125724 / https://bugs.kde.org/show_bug.cgi?id=141267
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.