Bug 159989 - Focus follows mouse passes focus according to focus chain when currently focused window is closed - should behave like FocusUnderMouse
Summary: Focus follows mouse passes focus according to focus chain when currently focu...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Mandriva RPMs Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 187718 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-03-28 03:28 UTC by Richard Neill
Modified: 2012-07-02 21:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Neill 2008-03-28 03:28:37 UTC
Version:            (using KDE 3.5.9)
Installed from:    Mandriva RPMs
OS:                Linux

I use "focus follows mouse". 

When I close a window, focus jumps to the LAST window which had focus, even though this is NOT the window which is now under the mouse. So the focus is in the wrong place.

Consider the following:

(1)I create 3 windows in kwrite, called  A,B,C.  All of these windows are raised(*). The left hand half of the screen contains window A and Window B,  with B on top of A.  The right hand half of the screen contains Window C.  First, I click on C. Then I move the mouse pointer over B and click it.

(2)Now, I close Window B.  (It makes no difference whether I use Ctrl-W, or the [X] button.)

(3)The mouse pointer has not been moved, and is now over window A. So, A OUGHT to receive focus. However, focus actually jumps to the previously active window, C.

(4)I am now typing in the wrong window.


I hope that report is helpful. It's especially annoying on dual monitors, though I can reproduce it on a single monitor too. 

(*)Just to clarify, I am using "raised" as the opposite of "minimised into the taskbar". Is that the correct term? Obviously, they aren't maximised, or they would each be full screen.
Comment 1 Claus Wilke 2009-01-08 21:10:16 UTC
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.
Comment 2 Claus Wilke 2009-01-08 21:17:55 UTC
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.
Comment 3 Georg Wittenburg 2009-01-11 23:05:03 UTC
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.
Comment 4 Georg Wittenburg 2009-07-24 15:38:12 UTC
Still reproducible in 4.3 RC2.
Comment 5 Melchior Franz 2009-07-26 18:02:58 UTC
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.
Comment 6 Melchior Franz 2009-08-04 13:56:10 UTC
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!  :-)
Comment 7 Georg Wittenburg 2010-03-07 09:25:17 UTC
Still present in 4.4.1 (reproducible as described in comment #3).
Comment 8 Jaime Torres 2010-10-10 10:14:25 UTC
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.
Comment 9 Thomas Lübking 2010-10-11 00:30:28 UTC
*** Bug 187718 has been marked as a duplicate of this bug. ***
Comment 10 Georg Wittenburg 2011-05-15 16:34:54 UTC
Fixed in 4.6.2.
Comment 11 Thomas Lübking 2011-05-15 22:45:05 UTC
@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
Comment 12 Richard Neill 2011-08-10 01:30:36 UTC
I'm still seeing the original bug in 4.6.3. 
(incidentally, I do have click-raises-active-window set)
Comment 13 Thomas Lübking 2011-08-10 03:07:10 UTC
Please see comment #6.
Comment 14 Richard Neill 2011-08-10 03:53:21 UTC
(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.
Comment 15 Thomas Lübking 2011-08-10 18:38:19 UTC
> 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
Comment 16 Richard Neill 2011-09-21 02:48:43 UTC
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.
Comment 17 Thomas Lübking 2011-09-21 11:58:14 UTC
> 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?
Comment 18 Richard Neill 2011-09-21 12:38:37 UTC
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  :-)
Comment 19 Thomas Lübking 2011-12-01 12:29:11 UTC
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
Comment 20 Richard Neill 2012-07-02 21:24:23 UTC
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
Comment 21 Thomas Lübking 2012-07-02 21:45:55 UTC
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 :-\