When autoraise is enabled, switching workspaces or closing an active window raises the window that happens to be under the mouse instead of respecting the current stacking order. This is wrong and annoying, especially when frequently switching virtual desktops, because it messes with the target workspace's stacking order when the mouse has been moved between two switches. The problem is even worse when focus-follows-mouse is also enabled. Focus-follows-mouse correctly assumes that it should not activate the window under the mouse unless the mouse has actually been moved. In result, the window that's autoraised is often an inactive one, hiding the window actual active window. This is a regression to KDE 3.5. The fix is simple: autoraise needs to respect the same mouse-has-been-moved constraint that focus-follows-mouse uses. Attaching patch. Tested with kwin 4.7.2 (installed on my OpenSUSE box). Patch forward ported to kwin git-master. Reproducible: Always Steps to Reproduce: Reproduce when closing active window: 1. Enable focus-follows-mouse and autoraise 2. Open three windows, A, B, C. Have B and C partially overlap. Place A over C. Establish stacking order: A (focused) -> B -> C. 3. Move the mouse into A. Close window A using a keyboard shortcut (typically Alt-F4). 4. Result: Window B will receive focus (according to stacking order), but window C will be raised over B (because the mouse will now be over C). Reproduce when switching virtual desktops: 1. Enable focus-follows-mouse and autoraise 2. On workspace 1, open two windows, A and B. Focus and raise A. 3. Switch to workspace 2 using a keyboard shortcut (typically Ctrl-F2). 4. Move the mouse so that it is over window B when switching back to workspace 1. 5. Switch to workspace 1 using a keyboard shortcut (typically Ctrl-F1). Now window A will (correctly) remain focused , but window B will be raised. Actual Results: In each case, the window under the mouse is raised, but not focused. This can lead to an unfocused window obscuring a focused window. Expected Results: The unfocused window should not have been raised. Autoraise should be predicated by a mouse move.
Created attachment 73666 [details] Proposed patch: predicate autoraise on moving mouse
No idea whether that's a regression (ie. how it behaved on 3.5) but feels wrong. Please move the check before the more expensive topClientOnDesktop() Do you have commit rights? Otherwise please provide a "git format-patch" so we can commit on your behalf. And thanks for the notice & patch, btw.
Created attachment 73672 [details] Proposed patch v2: predicate autoraise on moving mouse Thanks for your quick feedback. Updated patch attached. No, I do not have commit privileges.
Patch is fine and works @Martin: any comments from your side? (9/10, "no way" ;-) @Michael: Thanks again, ideally http://use git.reviewboard.kde.org to get future patches reviewed (if there will be such)
only commit is that I will be very happy about that fix :-) And I'm quite sure this report is a duplicate, but I cannot find it
Git commit 6d098c60a5b998b6eb23cd6a30ffce8858f0aa16 by Thomas Lübking, on behalf of Michael Hohmuth. Committed on 04/09/2012 at 23:36. Pushed by luebking into branch 'KDE/4.9'. Do not autoraise a window unless the mouse has been moved. Fixes unintended autoraises when switching workspaces. FIXED-IN: 4.9.2 M +2 -1 kwin/events.cpp http://commits.kde.org/kde-workspace/6d098c60a5b998b6eb23cd6a30ffce8858f0aa16
(In reply to comment #5) > only commit is that I will be very happy about that fix :-) And I'm quite > sure this report is a duplicate, but I cannot find it Isn't this 'related' to 92290?
focus != raising I don't know whether there's an actual dupe. FTR: original bug #92290 lead to the introduction of the last_mouse_pos variable, last remaining part was about unhiding dropdowns (and similar windows)