Bug 183911

Created attachment 34049 [details]
cropped screen shot showing a focused window that is not raised

How to reproduce:

1) launch thunderbird and firefox

2) reply-to an email. There are three windows open, and the reply is on top. Arrange windows so that all three are partially visible.

3) Click the firefox window to raise and focus it.

4) Move the firefox window so you can see the title bar and closing box on the reply-to window.

5) Click the closing box on the reply-to window. Focus will go to the thunderbird window, however, the unfocused firefox window will be on top. See the attached jpeg.

I've tried different settings in the click-to-focus window behavior. It has no effect on this bug. With click set to "active and raise", but *not* pass the click through you will find that clicking the interior of the focused, non-raised thunderbird window will *not* further raise or activate it. The border of the thunderbird window must be clicked. This bug is reproducable even with "active, raise, and pass click" is enabled.

I just tried to reproduce with combination of kmail and konqueror and I was not able to reproduce. Could that be a special case of thunderbird? Are you able to reproduce with non Mozilla applications?

Yep, I just reproduced with Emacs (as well as Firefox) and two windows from Konsole. It might be related to the task bar's concept of where to focus when there are several windows open for an application, and one of that application's windows is closed. Instead of giving focus on the window at the top of the stack of windows, focus is given to a window from the application whose window was just closed.

I run Konsole, then open another Konsole window with ctrk-shift-m or New-Window. Click and drag to get windows stacked in this order:

top window: second Konsole window which will be closed
middle window: Firefox 
bottom window: first Konsole window that will get focus, but not raise.

Close the top konsole window. Focus goes to the bottom Konsole window, and keystrokes go to this window.

Also reproduced with Emacs and two Konsole windows. The stacking order/click order is key. Create all 3 windows. Raise and focus Emacs/Firefox. Raise and focus the second Konsole window. Close the top Konsole window.

I seem to be running KDE 4.2.2-5 for fc10.

[tull ~]$ uname -a
Linux tull.achs.virginia.edu 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 i686 i386 GNU/Linux
[tull ~]$

I am probably experiencing the same issue with KDE 4.3.1 on ubuntu. If the window stack top to bottom is like this: firefox, something non-firefox ( say konsole ), firefox, closing the top firefox transfers keyboard focus to the bottom firefox but doesn't rise it so konsole remains on top. This can get extremely confusing if the konsole is maximized for example.

The solution appears to simply be unconditionally rising windows when they gain focus, even if the previously focused window belongs to the same application.

Still happening in 4.3.2 on ubuntu 9.10

It seems that kwin focuses the most recently used *related* window instead of just the most recently used window (as it has for the last over a decade).  It should definitely either raise the (unexpectedly) focused window, or follow the old behaviour.  Preferably the latter.

*** This bug has been confirmed by popular vote. ***

Created attachment 39173 [details]
First attempt

(In reply to comment #9)
The fix seems trivial enough, but I'm not sure if this is desirable behaviour when the focus policy is something like focus-follows-mouse. Advice welcome.

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

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

Question: why does kwin focus the most recently used window from the same program instead of the most recently used window overall?  Why is this only applied to focus, not order?

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

Still exists in 4.5.1. A few times I have erroneously entered data, and even alt-f4 closed wrong applications by accident, because the foreground window was not actually the one that had the focus, and hid the window that did have the focus. It's particularly easy to miss using plasma-netbook configuration as every window is maximised. It's confusing and irritating behaviour when it bites you.

I see i'm not the only one that lost work/data because of this.

@kwin dudes: What can we do to make the fix come quicker? I see there is a patch in #9, have you guys had a look at it? If it's not Ok, can you hint at what part of KWin might be the responsible one?

Thanks

This might be useful:

It seems to be reproducible with any two programs, where one hosts two focusable windows in a single process. So with two konsole windows and some other window (e.g. kate) the described behavior is reproducible, with two konqueror windows it isn't.

Also, I think, this could be considered a security risk. It's easy to mistakenly type in sensitive data into a focused but hidden application. Especially since some applications (e.g. a bash hosted in konsole) don't give much visual feedback when entering your password.

hmm, I think I commented on one of the duplicates... anyways, +1 for fixing this. I'd also prefer last-window instead of last-window-in-that-process.

it probably needs upgrading to take activities into account anyways, so maybe I should take a look at that code (not today though)

> @kwin dudes: What can we do to make the fix come quicker? I see there is a
> patch in #9, have you guys had a look at it? If it's not Ok, can you hint
> at what part of KWin might be the responsible one?
Patches attached to bug reports are easily lost. I would say that we are 
simply overloaded by too many bugs and we are in a state where bugzilla is a 
burdon and not a help. Maybe the patch should be opened at reviewboard?

"fix" that is simple. (patch in #9 is wrong.
the behaviour was (likely) changed on commt 802097
// http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/activation.cpp?r1=742984&r2=802097 (lunakl)

choose the "fix" is hard, either 
- revert the commit and only consider mainwindows
- apply this patch (ignore siblings entirely)

Index: activation.cpp
===================================================================
--- activation.cpp      (Revision 1180288)
+++ activation.cpp      (Arbeitskopie)
@@ -455,11 +455,13 @@
                     if( c == NULL && !ci->isOnScreen( activeScreen()))
                         continue;
                     }
-                if( windows.contains( ci ))
-                    {
-                    get_focus = ci;
-                    break;
-                    }
+                   // http://websvn.kde.org/trunk/KDE/kdebase/workspace/kwin/activation.cpp?r1=742984&r2=802097
+//                 if( windows.contains( ci ))
+//                     {
+//                     get_focus = ci;
+//                     raiseClient( ci ); // also raise - we don't know where it came from
+//                     break;
+//                     }
                 if( get_focus == NULL )
                     get_focus = ci;
                 }

- uncomment this patch (raise them)
- make the patch more complex (check whether and how much the candidate is obscured)

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

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

http://svn.reviewboard.kde.org/r/5830/

SVN commit 1208125 by luebking:

adjust activateNextClient() policy
(on a client close, don't activate any random client in the 
group but only the leader -and raise it- or the last active client)
http://svn.reviewboard.kde.org/r/5830/
BUG: 183911


 M  +24 -20    activation.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1208125

Thanks Thomas, can't wait to see this shipped in next KUbuntu!