Bug 336134

This also holds for 4.x and there's hardly a kwin bug here - kwin acts exactly as configured (high implies that the focus can only be passed inside a clientgroup and "focus under mouse" means that the focus is under the mouse - focus stealing prevention does not work _reliably_ by this)

Krunner/kickoff can still forcefully "steal" the focus by feigning a tool (pager) - seems acceptable in reaction to shortcut activation to me.

-> Any particular reason why you're not using "focus follows mouse"?

@Martin
What should pot. happen is to internally set the focus stealing prevention to "extreme" to get a more consistent behavior (since krunner/kickoff will get the focus regardless of the policy when they popup under the mouse) - focus stealing prevention does not work "reliably" since it can/shall not prevent the focus from a window the appears under the mouse, but it can still interfere with client focus requests - and by this actually also violate the focus strategy (focus away from the mouse)

Sorry, I played to much with focus settings and got confused. 
I actually mean:
1. set focus follows mouse and focus stealing prevention = high

I have inconsistent raising behaviour, when i set focus stealing prevention first to high and then  back to normal. 
Some programs (inkscape, acroread, firefox) open under the konsole window and others (okular, gimp, konqueror, konsole) open on top the konsole window when started from konsole.

the krunner behavior for high FSP is "expectable" - it's still a window that gets the focus from some other one (konsole) what is generally forbidden by this policy.
- make an exception rule
- "Krunner/kickoff can still forcefully "steal" the focus"

for normal, the behavior is usertime related - this is a property set on the window.
if it fails for "normal" that means no valid time is set, what either means the client didn't (*sounds* like, since it seems to work with -all?- Qt applications and fails with most gtk+ applications) or it's the "userTime() is out of date" bug - do you have commit 7910fed659b2b0c5d2d7c15880b290fd444e7135 ?

"Low" will let it pass in either case.
I want FSP re-designed for ~5.1 anyway.
   https://git.reviewboard.kde.org/r/110919/
   https://git.reviewboard.kde.org/r/110918/
Those won't apply on git master, though.

> do you have commit 7910fed659b2b0c5d2d7c15880b290fd444e7135 ?
00:09 builder: /var/sam/abs/sources/kwin$ git branch --contains  7910fed659b2b0c5d2d7c15880b290fd444e713
* master
Does that mean "Yes" ? Is that good or bad?

> the krunner behavior for high FSP is "expectable"
But krunner should recognize that doesn't have focus and stop the cursor blinking. 

> - make an exception rule
I'll do that, when systemsettings stops crashing on me, thanks.

(In reply to comment #4)
> 7910fed659b2b0c5d2d7c15880b290fd444e713
> * master
> Does that mean "Yes" ?
If you compiled the master branch ;-)

> Is that good or bad?
It means the usertime should be up-to-date - the gtk+ applications simply don't set one on mapping (or set an outdated one)
I'll seek for some gtk+ client and re-check that assumption.
 
> > the krunner behavior for high FSP is "expectable"
> But krunner should recognize that doesn't have focus and stop the cursor blinking. 
Sure. I assume this is a bug and/or weirdness in either qt, qml or the plasma components.
Does it stop blinking when moving the focus to/from krunner the regular way?

> I'll do that, when systemsettings stops crashing on me, thanks.
You should be able to access the rule dialog via the "special window settings" of any window - you can alter the window matching in the first tab.

> Does it stop blinking when moving the focus to/from krunner the regular way?
Yes.
By the way, with KDE4, I get the expected results.

can you try KRunner/4 on KWin/5 (this works like KWin/4 and as expected here, ie. krunner does not get the focus nor indicates it)

Yes, KRunner/4 grabs the focus on KWin/5. It doesn't matter if i come from KWin5/KRunner5 or KWin4/KRunner4.

krunner/4 should rather not (easily) get the focus for "high" FSP.

However re-assigning to plasma.
I assume this is related to qml, might be a Qt bug.

What should happen in the first place is that the window invoked by a shortcut forcefully takes the focus.
In addition, if it does not have the focus, the GUI should reflect that.

This bug is still happening in 5.6.5. I have Focus Stealing Prevention set to "High" and both krunner and Application Launcher immediately vanish when they're invoked (by pressing ALT-F2 and clicking on the icon, respectively). Setting FSP to "Medium" or lower immediately resolves the problem. "High" and "Extreme" both exhibit the problem. Also, I have "Click to Focus" set; I never use any form of Focus Follows Mouse.

Since it's marked as "unconfirmed", I add my case: same behaviour as described in the previous comment (#10).
Using Gentoo Linux with KDE 5 (Plasma 5.10.4, frameworks 5.36.0, apps 17.04.3).

I am not sure if it is fixable from Plasma's side. The actual issue is in KWin, see bug 377914.

Can confirm this bug

Distribution: KDE neon Developer Edition - Stable Branches
Plasma: 5.11.3
Frameworks: 5.41.0
Qt: 5.9.2
Kernel 4.10.0-40-generic
Type: 64-bit

Looks related to https://bugs.kde.org/show_bug.cgi?id=363897 and https://bugs.kde.org/show_bug.cgi?id=336285

I can confirm this issue and i DONT use focus follows mouse.

If i set focus stealing prevention > high laucher and caledar does not open. I can see some frame of the animation sometimes.

(In reply to lestofante88 from comment #14)
> I can confirm this issue and i DONT use focus follows mouse.
> 
> If i set focus stealing prevention > high laucher and caledar does not open.
> I can see some frame of the animation sometimes.

Same here

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

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

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

Created attachment 124039 [details]
Monitor Layout

I have been experiencing this issue since kde 4 was deprecated by my distribution. The problem was generally intermittent for me up until the latest Plasma update (5.17.3).  Now the problem seems to be stuck in the borked state every time plasma starts.

I noticed some of you were having a hard time replicating this issue, so let me describe some of my observations.  This issue only seems to happen with two monitors of differing resolution.  I currently have a 4k monitor @30Hz and a 1k monitor @60Hz.  The 4k display is setup on the left of the 1k and is set to the primary display.  The smaller 1k on the right is setup where the bottom edges align, but the top of the smaller monitor starts below the top of the larger.  I have attached a screenshot for clarification.  In case it matters, I am using a Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] with the mesa drivers (19.3.0_rc3) and this is a Gentoo Linux machine.

I boot to a command line login and start X11 + Plasma with startx.  The plasma shell is initiated from ~/.xinitrc as `exec ck-launch-session dbus-launch --sh-syntax --exit-with-session "/usr/bin/startplasma-x11"`.  After plasma starts, I notice the following issues related to this bug: 

    1) Plasma Application Menu and tray expansion menu are offset as if they were calculated for position on the smaller 1k monitor.  The offset of both menus appears to be borked by about the same amount. Screenshots attached.

    2) Desktop Icons and Widgets are arranged as if the 4k monitor was only 1920x1080, but after Plasma starts I can rearrange the icons and Widgets.

I can resolve the issue in the following ways:

    1) Remove the power connector for either monitor, then startx.

    2) `kquitapp5 plasmashell; plasmashell`

My best guess as to what is happening is that one of the two monitors becomes available to Plasma before the other and Plasma just assumes that there is only 1 display.  This is problematic when the 1k display is the one detected first, as all of the correct ratios are in-place when the 4k is detected first.  Both displays are up and running when logging into the command line and are mirrored with the 4k display scaling down to 1k. I can only speculate that the display availability is effected by switching to OpenGL as X11 starts which is causing a race condition in Plasma's display detection.

A note on focus stealing prevention.  I have had my setting at low for a very long time, so I highly doubt that is the root cause of this issue.

Ef. I posted to the wrong bug.

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

(In reply to Nate Graham from comment #22)
> *** Bug 415759 has been marked as a duplicate of this bug. ***

Then the report's title is not correct: 

Focus 'stealing prevention = high' _only_ already satisfies the condition to trigger the bug. 

Still happening at 5.17.5 and probably under 5.18 too.

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

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

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