Neither device nor regular notifications cause this here.

The popup needs to request the input focus (ie. become active) to alter the state of the dimming effect.

If a "random popup" requests the input focus w/o reason, that popup is buggy and needs to be fixed (KWin can not know that a window is "a widget"- it has no deep insight into the windows content or nature.)

Kinda falls into categories of bug #314749, but as mentioned: the notifiers don't take the input focus here (therefore not alter the active window, thus not the dimming)

-> Please specify the notification system you use
(Ubuntu? -> "ayatana" or "colibri"?)

I don't know the name of the notification system I'm using. It is the default one of KDE SC.
When I deactivate the dimm effect the popups, like the device manager and notifications don't dimm the active window...

It's not colibri and it is not ayatana according to apt. Ayatana is not available and colibri is not installed.

Of course there's no dimming w/o the effect ;-)

-> if this happens, is the window you were working on actually still the active one (ie. has keyboard focus and a blue outline from the oxygen decoration)?

Please attach the output of "qdbus org.kde.kwin /KWin supportInformation"

output of "qdbus org.kde.kwin /KWin supportInformation": http://pastebin.com/ayfGYHyj

Well, the window I was looking at was the only bright one and not dimmed so I guess it was active and also had the focus....

The question is whether it still has the focus after the notification showed up.

If yes, the issue would be somehow in the effect misassuming the active window.
If not, the bug would be the popup "stealing" the focus in the first place.

I'll have an eye on it, need to wait until it happens again.

The window loses the focus when the popup appears. Mainly the culprit seems to be thunderbird. I know it's not a KDE application but I wonder why the problem didn't appear before KDE SC 4.10 (the thunderbird version is the same as before).

(In reply to comment #8)
> Mainly the culprit seems to be thunderbird.

Well, who would have thought such? ... ;-)

Is it thunderbird loosing the focus, thunderbird causing a notification that occupies the focus or a thunderbird internal popup that causes this?

If you can reproduce it, please move to VT1 , login and run
DISPLAY=:0 xprop -root _NET_ACTIVE_WINDOW

that will get you a number like
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x2200018
                                                                                ^^^^^^^^^^^

please obtain information about this window:
DISPLAY=:0 xprop -id 0x2200018 > active_window.props
DISPLAY=:0 xwininfo -wm -id 0x2200018 > active_window.info

Please attach both here.

If the focus is actually moved to the "popup", you can workaround this with a window rule on focus stealing prevention resp. just forbid this window to get the focus ever.

> problem didn't appear before KDE SC 4.10
*shrug*
Altered focus stealing prevention or focus policy?
Multiscreen issue?
Different virtual desktops / activities?

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

It is not only Thunderbird. There are other notifications (printer messages e.g.) that steal the focus. I have gotten a lot less focus stealing since I disabled the notifications for applications in the notifications setup but the popups then are always in the way so that'S no option - and sometimes it happens with no popup at all (open windows in that case were only chromium and dolphin).

I cannot reproduce the focus stealing in a certain case...

Ok, but what is really needed is an information about the window as provided by "xwininfo", "xwininfo -wm" and "xprop"

What i get here is a managed client which demands attention (ie wanted to be activated, what's bad enough) but is (very important) also
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL

and docks don't get the focus. Period. ;-)

I also removed the notifications from the panel and added them to the desktop -> same result.

If i however remove all notification widgets, i get windows of type
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_UTILITY, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL

Which *could* get the focus, but don't try here.

It definitely is not thunderbird as it happens also without. Now that I have activated the Nepomuk indexer my session nearly isn't usable anymore because once twice every second I have to click into the window I am in to reactivate it. Typing is really hard, as it also interrups that.

Created attachment 79796 [details]
output of DISPLAY=:0 xwininfo -wm -id 0x2200386

When the active window gets "lost" it seems as if the desktop itself is grabbing the attention...

Created attachment 79797 [details]
output of DISPLAY=:0 xprop -id 0x2200386

Sorry, the other file is the output of xwininfo!

That's a dock and kwin usually won't activate it.

The two only ways it could obtain the inputfocus would be 
a) completely bypassing the WM and just XSetInputFocus itself
b) calling KWindowSystem::forceActiveWindow()

Try to setup a rule for that panel ("kcmshell4 kwinrules", press detect and pick the panel where you notifier resides) to forcefully not get the focus (last tab, "Accept Focus"/"Force"/"No")
If this prevents the problem, the panel is somehow invoking KWindowSystem::forceActiveWindow()

(In reply to comment #16)

> Try to setup a rule for that panel ("kcmshell4 kwinrules", press detect and
> pick the panel where you notifier resides) to forcefully not get the focus

That seems to work...  

Now the active windows only seems to lose the focus when I click on the desktop (shouldn't be either iMHO, it shouldn't be necessary to re-activate the former acitve window after using the desktop context menu) and when I use the pager in the panel to switch desktops (also not desired behaviour - and it doesn't happen when I switch desktops via mousewheel)...

(In reply to comment #17)
> (In reply to comment #16)
> 
> > Try to setup a rule for that panel ("kcmshell4 kwinrules", press detect and
> > pick the panel where you notifier resides) to forcefully not get the focus
> 
> That seems to work...  
Ok, then this is likely a forceful client request.
You can probably not use wireshark to inspect the X11 communication, can you? Or inject a patch for debug out?

--------------

OT. in doubt please open a new bug for this:
----
> Now the active windows only seems to lose the focus when I click on the desktop (shouldn't be either iMHO

Generally passing clients clicks w/o activating them is simple but "risky", afaik no WM does that. Could lead clients to crash or just not work.
-> Would be an experimental setting at best, with uncertain impact.

The desktop will need to be focusable for random plasmoids, but you can in theory setup an equal rule to prevent it from being focused.
Alternatively, the desktop can opt-out of general focus handling and fetch the focus on particular buttons only (this works, doing it myself ;-) what would also work with any NETWM windowmanager.

> and it doesn't happen when I switch desktops via mousewheel)
The mousewheel is long time (ever?) passed on w/o focusing the client.
So this is just less problematic.

> You can probably not use wireshark to inspect the X11 communication, can you? Or inject a patch for debug out?

Never did something like that before... Sounds complicated? Maybe if you can explain in very detail.....

I wanted to post a bug report about "Windows always lose focus without identifiable cause" and this report appeared in the search results at first position - seems to be related?

I am using KDE SC 4.10.3 and I don't use thunderbird but my windows very often get out of focus, even when I write something in some application window, the window suddenly loses the focus and I type into the big void...

As proposed in comment #16 here I created a non-activation rule for - not the panel - but everything containing the word "plasma" as long as it is no normal window or dialog window. And that seems to eliminate the focus stealing so far...

Focus stealing prevention level is set to "low" (because otherwise new windows don't open on top, I use that level since I use KDE and I never had those problems before 4.10), the dim effect for inactive windows mentioned here is activated.

(In reply to comment #9)

> > problem didn't appear before KDE SC 4.10
> *shrug*
> Altered focus stealing prevention or focus policy?
> Multiscreen issue?
> Different virtual desktops / activities?

No multiscreen, no altered focus stealing prevention ("low" for eons), no changed virtual desktops/activities constellation (5 virtual desktops, only 1 activity), just update to KDE SC 4.10...
Also no changed window rules. 

I have some window rules (had them before without problems) to get login/password dialogs always on top and activated: window class (exact): "kdesu" and window class (exact) "kwalletd kwalletd" + window title (exact) "KDE-Dienst für digitale Brieftasche"... and icedove reminders (window class (exact) "icedove", window title contains "Erinnerung").

I assume this is related to the notification plasmoid moving to QML.

@Plasma devs: from grepping sources, this

void PanelView::statusUpdated(Plasma::ItemStatus newStatus)
{
    if (newStatus == Plasma::AcceptingInputStatus) {
        KWindowSystem::forceActiveWindow(winId());
    }
}

looks like the best candidate to cause this.
Unfortunately i was not able to reproduce this, but in general wonder why (if the function does as it suggests) just updating capabilities (is it) should cause a (forced!) focus request.

Reassigning for clarification and because the issue likely needs to be fixed in plasma anyway (::forceActiveWindow() is the "i know better" command and the WM is expected to respect that - it should for that reason be invoked on direct user interaction only)

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

Maybe realted: Bug 314651 ?

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

Excuse me, why is this wishlist and not bug? The focus losing really is a problem that affects the workflow and I cannot image that it is intentional, or is it?

Started out as "kwin effect to dimm inactive windows should have an option to exclude widget popups", ie. focusing on avoiding a correct result of the unwanted incident.

FWIW, the simplest reproducer here is to unplug (resp plug in if previously unplugged) the power cable of the laptop. Also happens in other (less predictable) cases though.

I usually manage to prevent these focus changes by adding an "Accept focus: force no" rule for all windows matching "plasma-desktop" (exact match). (However, it seems that after a kwin --replace, the rule has no effect anymore, which is an unrelated issue though).

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

for me a rule of window title "plasma-desktop" + all types except "normal window" seems to help (including normal window prevents alt+f1 menu from getting focus)

Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham