Although I can reproduce it, I have no idea what might be causing this.

Happens also with Kopete, so I assume KWin or kdelibs problem, reassigning to KWin for now.

To me this is the expected behaviour. Each window is independent. So closing the topmost window in the stacking order will of course give focus to the next window in stacking order - which is in that case konsole.

I am not aware of any change concerning handling of stacking order. I will try to reproduce with 4.2 - as said I'm expecting the same behaviour there.

READ better, Konsole is NOT getting the focus, that's what i complain about

(In reply to comment #3)
> READ better, Konsole is NOT getting the focus, that's what i complain about
sorry totally missread the last point :-( so forget my comment

And I'm able to reproduce in 4.3 and will try with 4.2

just tested with 4.2 and the behaviour is reproducable as well.

Confirmed on KDE 4.3.1 r163 (opensuse/packman rpms) using multiple windows of thunderbird, or firefox, or konsole. When an application has multiple windows open, closing one of the windows brings focus to another window of the same application, NOT to the next window in the stacking order (unless of course that window belongs to the same application). The newly focused window is NOT brought to front, so it is not very visible that this happens. This has several times caused me to type into or even close the wrong window - potentially a quite harmful bug.

I confirm this is not an issue with kmail or konsole, it is general and probably lies within kwin.

Wondering why there is little activity on this. I'd expect hordes of people to be annoyed by it. Does it only happen for some users, perhaps?

the code is in activation.cpp - apparently the "other group members first" policy is intended.

replacing line 456

   requestFocus( get_focus );

with

   takeActivity( get_focus, ActivityFocus|ActivityRaise, false );

would raise the new client, what sounds reasonable to me (as either the window /is/ on top as it's next in stack or it gets focus by the group exception handling) but there might be other reasons to not raise it...

Thomas Lübking:
group members = other windows of same application?
new client = ?

"focus stays within application" would be less likely to cause data loss if windows were raised when they got focus, but this does not happen (no matter which "focus stealing prevention level" in System Settings > Window Behavior > Focus). The way it is now is counter intuitive:
* Focus a Konsole window
* Focus a KWrite window
* Open another Konsole window, close it again
* Kwrite is now on top, but Konsole has focus
* Type something, the input goes to Konsole
(Tested at all five focus stealing prevention levels, KDE 4.3.3.)

Can this really be intentional??
Expected: In the example above, focus should go to KWrite when the second Konsole is closed.

all konsole windows run in one process, that's why they're considered siblings

i read the "intention" from a comment in the code - but have no deeper insight to it.

as mentioned i'd find an autoraise reasonable, but am not in position to decide as i simply know far to few (read: "nothing") about the reasons behind the current behaviour.

please keep in mind that the current behaviour collides with /your/ usecase and setup (click to focus) but _may_ be crucial to provide other setups (focus under mouse or whatever) i.e. an uninformed changed could screw other things deeply (eg. cause race conditions or whatever), that's why i can only point the relevant code change atm.

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

I think there's little activity on this because it's not obvious what's happening unless you're actively looking for it.

Since updating to KDE 4 over a year ago, I noticed that kwin would often (but not always) leave nothing in focus after closing a window. I realize now that it wasn't nothing, but the very subtle default window hint for the in focus window plus a large number of open windows made me unable to see what was in focus, other than the fact that it wasn't the window I was expecting to be in focus.

For me, at any particular time I normally have more konsoles open than all non-konsoles combined, so I don't run into this especially frequently. (see bug 228714 for further explanation)

Anyways, while annoying, the above factors are what kept me from reporting this bug until now. Had the bug occurred every time instead of just sometimes, or if it was obvious that the wrong window was in focus, I almost certainly would discovered how to reproduce it, and then reported it within a day or two of trying KDE 4 for the first time.

In bug #183911 there is a patch attached, just in case anyone wants to try

*** This bug has been marked as a duplicate of bug 183911 ***