Version: (using KDE 3.2.0, compiled sources) Compiler: gcc version 3.3.3 [FreeBSD] 20031106 OS: FreeBSD (i386) release 5.2-CURRENT I have my mouse focus policy set to "Focus Follows Mouse". On the "Advanced" tab, "Focus stealing prevention level" is set to "Low". I'm reading e-mail in Mutt in an xterm. While reading through, I stop what I'm doing, flick the mouse down to the panel, and start xchat from a button in the panel. Then I move the mouse back to the xterm running Mutt. The xterm gets the focus. I continue reading. The xterm's quite long, so by the time I've read down to the bottom of the page, xchat has finished starting up. I hit the space bar to go to the next page of the message, and discover that xchat has got the focus, and my key strokes have gone there instead. I can see a security risk here -- suppose you're about to type a password in an xterm, or other app, then start a new app, then start typing your password. The new app gets the focus, and hence the password. This seems to be standard behaviour no matter which applications are used. For example, start an xterm, start another one, and while the second one's starting, put the mouse back in the first xterm's window. Even though the mouse pointer stays in the first xterm, the second xterm gets the focus. I have to move the mouse out of the first xterm, and back in to it, to get the focus back there. This does not match the description for "Focus follows mouse", and is counterintuitive. I can't see an option for "newly created windows get focus" in the control centre. If I set the policy to "Focus under mouse" I get the expected behaviour -- specifically, the focus is always under the mouse. Is this a bug with the implementation of "Focus follows mouse", or a problem with its description?
What you want is the focus under mouse policy, for click to focus and focus follows mouse policies it's the focus stealing prevention setting which controls whether new windows get focus or not. The descriptions have been already changed to stress this more explicitly (it already said that before as well - 'moving the mouse pointer _actively_'). The focus stealing prevention didn't do anything in this case because you did not explicitly activate the xterm again, so from KWin's point of view your last activity was starting xchat. Unfortunately there doesn't seem to be a way how to distinguish mouse-enters-window events caused by the user from those caused by window structure changes (that's more for bug #72641).