Bug 159989

This bug still exists in KDE 4.1.3. Moreover, with auto-raise enabled, window A moves to the top but window C continues to have focus.

The bug may be related to bug 180059. I think the underlying mechanism that connects both bugs is that if an application has more than one window open and one of its windows is closed, then the focus goes to the top-most window of the same application, regardless of where the mouse is.

Regarding my earlier comment, "...the underlying mechanism that
connects both bugs is that if an application has more than one window open and
one of its windows is closed, then the focus goes to the top-most window of the
same application...":
This is not true. The focus goes actually to the last window (of the same application) that had focus, not to the top-most window. The way to check this is to switch off auto raise, and to open 4 windows A, B, C, D. If they are arranged in order so that A is below B, B is below C, etc., and the focus is moved first to B and then to D, and then D is closed, the focus goes to B, even if the mouse is in A or C.

I'm seeing something quite similar in 4.1.96 (using unofficial Debian packages from kde42.debian.net at version 4:4.1.96+svn907177-0r1). The main difference to this bug report is that I'm using "Click to focus" rather than "Focus follows mouse".

How to reproduce (example):
Open dolphin (window A)
-> open konsole (window B)
-> open dolphin (window C)
-> close dolphin (window C)
=> The other instance of dolphin (window A) gets the focus. Konsole (window B) is the topmost window.

Expected behavior: Konsole (window B) should get the focus, since it was the active window before dolphin (window C) was opened.

Still reproducible in 4.3 RC2.

This isn't only an annoyance, it has severe data-safety and security implications. Accidentally typing passwords in konversation rather than konsole is not so great, or typing 'rm *' in one konsole window that was meant for another.

To my embarrassment I have to admit that I mixed up FocusUnderMouse and FocusFollowsMouse. I had used the former in KDE3 and somehow managed to choose the latter in my KDE4 migration process. Suddenly window focusing became a major annoyance. Now I'm back at FocusUnderMouse and all is well. Frankly, I don't have the slightest clue about FocusFollowsMouse. Its (perceived) "brokenness" might be by design, and I can't say anything about the validity of this bug report, so I hereby withdraw my previous comment. Sorry for the noise!  :-)

Still present in 4.4.1 (reproducible as described in comment #3).

I can confirm it with KDE SC 4.6 trunk r1184129 following #0 steps, when none of the following are checked:

[ ] Raise, with the following delay:
[ ] Click raises active window
 
But there is a very simple workaround: select one of those checkboxes.

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

Fixed in 4.6.2.

@Georg: yes the behavior as described in comment #3 was fixchanged by this commit
http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=49aec653e8cb5b4e68df4da00c749c4de4894624

BUT:
it is NOT the originally reported bug (but a dupe of bug #183911) - which you (or rather Claus in comment #1) actually hijacked :-P

The original bug is still open and not a bug but a wish since FocusFollowsMouse only passes the focus to windows the user has intentionally hovered as Melchior has discovered in comment #6

I'm still seeing the original bug in 4.6.3. 
(incidentally, I do have click-raises-active-window set)

Please see comment #6.

(In reply to comment #13)
> Please see comment #6.

Thanks - I already did. This is a bug which affects focus *follows* mouse. 

According to the docs, I need to have focus follows mouse in order to ensure that a newly opened window will automatically receive the focus. (eg from a terminal, type "kcalc"; keyboard input should then immediately go to the kcalc window).

However, when I close a window, focus should then go back to the window which is now under the mouse pointer, NOT the window which was 2nd last to have focus.

I think there are 3 ways this could behave (in the case where the pointer is never moved):


(a) There is a (FILO) stack of windows which have focus. But launching a new window (from the keyboard) pushes that one directly to the top of the stack.
[When the newest window is closed, the 2nd last window receives focus.]
 =>  this is the current behaviour of Focus Follows Mouse.

(b) Focus is always under the mouse pointer. But when a new window is launched, that window gets the focus. [When the newest window is closed, focus goes to the window under the pointer]
 => this is, imho, the expected behaviour of Focus Follows Mouse.

(c) Focus is always under the mouse pointer. (When a new window is launched, it does not receive focus.)  [When the newest window is closed, focus goes to to the window (if any) under the pointer]
 =>  this is the behaviour of Focus Under Mouse.


Another consequence of (a) is as follows:

Here is a diagram (sorry for the bad Art). 

+-----------+-------------+
|        +--------[X]     |
|        |  |  C   |      |
|   A    +---------+  B   |
|           |             |
+-----------+-------------+

- Windows A  konsole) and B (konqueror) are adjacent. 
- C is kcalc, and is on top of both A and B.
- User moves the mouse from A onto C, and then carefully onto the 
  kcalc  window close button, [X]. 
- User clicks [X] once.
- User then moves the mouse about on top of konqueror (but doesn't click).

Clearly, the focus should be following the mouse, and should be in konqueror.
But it isn't: the focus is in konsole.  For the user to focus on konqueror, he must move the mouse right out of the window, and then back again!

This is very arbitrary: the window which has the focus isn't anywhere near the pointer; and depends on the path the mouse took to get there.

> this is, imho, the expected behaviour of Focus Follows Mouse

That's the problem: "imho".

The policy exists since the times of M. Ettrich and he defined it as:
"FocusFollowsMouse - Moving the mouse pointer actively onto a
normal window activates it. For convenience, the desktop and
windows on the dock are excluded. They require clicking." [1]

Ie. it's some sort of automated click-to-focus, not "focus under mouse with focus to new windows".
This is why i wanted to know whether you rather (expected|wanted to use) FocusUnderMouse in the first place.

Results:
a) your assumptions about what "should" be are wrong (sorry)
b) this report is a (correctly tagged) wish, not a bug
c) fulfilling your wish would mean a behavioural change on a not-bug. Therefore it can only be an option and even good reason to change the default behaviour.

------

The implementation would be to optionally invoke and prefer the pointer position in activateNextClient()
This can btw. happen regardless of FFM or CTF and could even be accomplished by the opposite, ie. to move the pointer to the window with the focus (E17 does that)

[1] http://websvn.kde.org/branches/KDE/3.0/kdebase/kwin/README?r1=48753&r2=54010

This is actually worse than it first seems:

1. Not only is focus not automatically transferred to the window under the pointer (so that, for example, pressing Ctrl-Q goes to the wrong window), but 

2. moving the mouse about over the window I want will still not put focus into that window...I have to move *away* from the window, onto the other screen, and back. This is surely not desirable.

FWIW, I think Focus follows Mouse should do the following:
 1. Normally, focus is always under the mouse.
 2.     [But, if the mouse is over no window, focus remains where it was.]
 3. If a new window is created, focus is automatically put there.
 4. If the window with focus is closed, goto #1.
 5      [But if there is now no window under the mouse, nothing receives focus.]
 6. As soon as the mouse pointer is moved, goto #1.
 
i.e. there are 2 key differences from current behaviour:

* Whenever the mouse pointer is moved, the window beneath it automatically receives focus. [even if the pointer doesn't change window]

* When a window with focus is closed, *don't* go back in time along the stack.
  Decide where to put focus based *only* on the layout of windows as they are
  now. [This may, if unlucky, mean nowhere receives the focus.]


Thanks for your help.

> This is actually worse than it first seems:
No, it's not.

(1) is being discussed here and there's also https://git.reviewboard.kde.org/r/102371/
(2) is called "focus under mouse" - it naturally breaks the focus policy for showing up windows and there's a major logical flaw in your suggested behavior

> 3. If a new window is created, focus is automatically put there.
> ...
> 6. As soon as the mouse pointer is moved, goto #1.

consequence:
pointer is above w1, w1 has focus. w2 shows up, w2 gets focus, user moves mouse, w1 get's focus again (now attach autoraise to that and you're really screwed)

FFM acts on crossing events ONLY. Has alaways, will ever. It's the only real difference to F(S)UM - everything else (focus chain support, thus focus stealing protection) is an indirect consequence.
The only exception can be made when closing a client by altering the strategy for the next client. That is a change from the behavior as has been since ever, thus is a WISH for a new feature, thus (and for the introduced GUI strings) can NOT apply before 4.8.

You didn't bother to read comment #15 at all, did you?

Thanks for the explanation. Yes, I did read #15, and sorry if I appear to be nagging: I should try not to get so annoyed with the computer when it closes the wrong window when everything else is going wrong! Maybe what I really want is "focus follows eye" :-)

> consequence:
> pointer is above w1, w1 has focus. w2 shows up, w2 gets focus, user moves
> mouse, w1 get's focus again 
>(now attach autoraise to that and you're really screwed)

Yes, that was what I meant, and would be desirable: w2 would get focus if the user is using only the keyboard, but as soon as the user moves the mouse, focus should go back to w1 (until the user actually moves the mouse over w2). 

However, given the interaction with autoraise, and the way that ffm is a case of automated helpful clicking, rather than (modified) focus under mouse, this is inconsistent. I look forward to 4.8  :-)

Git commit f7140b7ff0763335d3996ce3e635325d7a25bea7 by Thomas Lübking.
Committed on 22/08/2011 at 13:53.
Pushed by luebking into branch 'master'.

add mouse preference against focus chain

there's currently no GUI config item, use
   kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true
   qdbus org.kde.kwin /KWin reconfigure

BUG: 159989
CCBUG: 80897
FIXED-IN: 4.8

M  +59   -31   kwin/activation.cpp
M  +61   -46   kwin/kcmkwin/kwinoptions/windows.cpp
M  +2    -0    kwin/kcmkwin/kwinoptions/windows.h
M  +2    -0    kwin/options.cpp
M  +1    -1    kwin/options.h
M  +17   -0    kwin/workspace.cpp

http://commits.kde.org/kde-workspace/f7140b7ff0763335d3996ce3e635325d7a25bea7

Thanks again for this enhancement - it's excellent. 

May I request adding a GUI to control this?  Otherwise it's rather tricky to discover.

[If you prefer not to add a GUI for it, may I suggest adding a single line of text into the relevant systemsettings panel that points users to this bug report, or adding it into the tooltip that describes the various focus policy options.]

Thanks again - Richard

There's no general objection against a GUI config.

The kcm doesn't use a designer UI file and actually should have been redesigned and redone anyway - it just somehow fell off the table and this key with it, that's all - sorry :-\