Does this also happen when you try to reproduce it using a freshly created user account? What third party tools you have installed that could affect this window activation issue?

Most important question:
- which KDE version do you use (precisely, really git master?)
- which focus model do you use (ie. "click to focus" or "follow mouse")
  and especially:
- which client is activated instead?

- it's http://mirrors.isc.org/pub/kde/unstable/4.6.90/src/kdelibs-4.6.90.tar.bz2
- click to focus (same as I had in 4.6.4)
- if by client you mean window (konqueror, konsole, kmail, ...), than no window is activated at all
- I didn't add any third party tools, at least I don't know about any
- I've disabled desktop effects, but it is not helping

And it happens with new user account as well.

More questions:
- is only kate affected?
- what focus stealing prevention do you use and is there maybe a rule affecting kate in this regard?
- please run "kdebugdialog", filter for kwin, select "kwin" & "1212 kwin" and run kwin from konsole: "kwin --replace &", then trigger the issue and have a look at the output.
- very wild guess:
overactive kio notification dialog? - try to shutdown "kquitapp plasma-desktop"

(The activation code has not seen relevant changes since 4.5 -> 4.6 ... unless astyle broke it ;-)

The same reporter also reported bug 276652, which indicates there is a general problem with keyboard focus. Blind guess: Is there any multiple monitor configuration, so that focus goes to a second (unconnected) screen?

> Same thing happens it Konqueror or when a delete message in kmail
Answeres one of my questions.

I tend to think this could be some rule(s) (applied by the distro by default?) going wild, ie. match every window. (Both focus stealing as well as global shortcut blocking can be configured through them.)

@Ojec:
- does the global shortcut issue remain when you change the windowmanager (eg. run "openbox --replace", this oc. implies you've openbox installed)
- can you please run "kcmshell4 kwinrules" and see whether there are any entries and what happens if you delete them? (on the new account to not mess up your regular one)

- what focus stealing prevention do you use ...
There is "Focus stealing prevention level: low" under Window Behavior. But I tried None, Low, Medium, High, Extreme with the same result. I can't see any rule for kate.

-  please run "kdebugdialog", filter for kwin, select "kwin" & "1212 kwin" and
run kwin from konsole: "kwin --replace &", then trigger the issue and have a
look at the output.

... when I open file dialog ...
kwin(2577) KWin::Client::readUserTimeMapTimestamp: User timestamp, ASN: 11327679
kwin(2577) KWin::Client::readUserTimeMapTimestamp: User timestamp, final: 'ID: 94843896 ;WMCLASS: "kate" : "kate" ;Caption: "Open File – Kate" ' : 11327679
kwin(2577) KWin::Workspace::allowClientActivation: Activation: Belongs to active application
kwin(2577) KWin::Workspace::updateClientArea: screens:  2 desktops:  4
kwin(2577) KWin::Workspace::updateClientArea: Done.
kwin(2577) KWin::Workspace::createTile: Now tiling  "Open File – Kate"

... and when I close file dialog ...

kwin(2577) KWin::Workspace::updateClientArea: screens:  2 desktops:  4
kwin(2577) KWin::Workspace::updateClientArea: Done.

- try to shutdown "kquitapp plasma-desktop"

Didn't help.

- Blind guess: Is there any multiple monitor

There are 2 monitors, but second one doesn't get focus. When I opened file dialog (in kate) and closed it, kate lost its focus. Then I tried to type "konsole" and "Run Command" dialog appeared with konsole text filled in.

- can you please run "kcmshell4 kwinrules" and see whether there are any
entries and what happens if you delete them?

There were 3 rules, I deleted them, but it didn't help.

> KWin::Workspace::createTile: Now tiling  "Open File – Kate"

Can you please try to disable tiling? ("kcmshell4 kwinoptions", 5th tab "advanced")

It sounds like the plasma-desktop gets focus whenever a window loses focus. The plasma-desktop has a feature to automatically active Alt-F2 krunner on "unhandled" key presses, but I don't exactly know how/if it works with a "separated displays" multiscreen setup, see bug 276652 comment #5

Adding Plasma maintainers to check if that feature could cause issues.

Tiling is already disabled. But I tried to start my desktop with only one screen (no external LCD, no TV attached) and all my problems disappeared. So Christoph was right.

I believe this may be the same problem I am having using 4.7.1 (Kubuntu 11.10)
4.6.5 (Kubuntu 11.04) did not have this problem.

Steps to reproduce:
1. Enable one of:
	Focus Strictly Under Mouse
	Focus Under Mouse
	(does not happen for me with FFM or CTF, so maybe it is not the same?)
2. Start a program and open a few windows, placing them on top of each other.
   I use firefox in my test but have seen with others.
3. Close windows using the keyboard, when the top window closes the one below 
   the mouse should get focus but sometimes no window has focus. No keyboard 
   inputs seem to work until you click on a window or on the desktop itself, or 
   make a new window get focus by moving the mouse across a window border
   (but FSUM!).

In my case there was also a second monitor attached, and removing it seems to have "solved" the problem.

To me this is a very annoying problem since I tend to open and close a lot of windows. What additional information would help resolve this?

Created attachment 64794 [details]
Possible workaround for F(S)UM issue with closing windows.

I sprinkled some kDebug printouts over the kwin code and what fell out was this. 

When closing a window makes focus end up nowhere it does: (edited)
kwin(4083) KWin::Client::unmapNotifyEvent:
kwin(4085) KWin::Workspace::workspaceEvent: X focus set to None/PointerRoot, reseting focus, c:  'NULL' 
kwin(4085) KWin::Workspace::activateNextClient: c:  'NULL'
kwin(4085) KWin::Workspace::focusToNull:
kwin(4083) KWin::Workspace::requestFocus: c:  'ID: 85983247 ...' (window that was under the pointer)

When it works it never does that focusToNull() call. I have no idea why focusToNull followed by a window requesting focus does not lead to that window getting focus as it should. Some kind of race condition would explain why it only happens sometimes.

Attached patch seems to fix the issue I was seeing by blocking the focusToNull call for F(S)UM. Not necessarily suggesting it be applied to anything.

Ahhh... you're running two instance of KWin (not randr or xinerama multiscreen - right?) - they probably cause some race on the server
=> The issue likely is that kwin handles clients on screens it shouldn't touch at all but i guess we need a new setting for this (or be smart enough to detect the screen split)

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

Correct, no xinerama it is set up as 2 separate screens (dualhead). I think this config was selected back when I was using fvwm, testing Xinerama with KDE might be an option.

I have 2 kwin processes running now when I check, with the same session parameter.

Also worth noting that "I" am not running two kwin instances, something has decided to start two. Big difference :) Possibly something that changed in my last system upgrade because I have not always had this problem. How and what starts kwin for a fresh config/newly created user?

It's your multiscreen (two x screens, no xinerama) setup which does so.

If you've only one GPU, the suggested multiscreen setup for "joe user" would be using xrandr/TwinView (nvidia), succeeding multiscreen + xinerama.
(it allows for online changes, ie. w/o restarting X11)

The result is effectively one large screen but the w/m and plasma-desktop will (ideally ;-) allow you to treat them as completely independent or a shade between (ie have one large desktop & panels, but maximize windows per screen etc.)

I'll attach this to the general "please improve singleuser multihead" bug

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