Focus stealing prevention prevents focus stealing. This is applied to all windows be it windows of the desktop or other windows. The level you set prevents the application launcher from stealing focus - that's what it is doing. Plasma is not active, you try to open it and this means focus stealing. This works exactly as advertised.

You can use a window specific rule to lower the fsp for plasma dialogs.

I completely disagree, but whatever. It's a broken design for the desktop environment to be completely unaware of itself.

Nikos is right. Turning up the sensitivity of the focus stealing feature shouldn't break basic functionality. Even if we need to add a special case to keep the Application Launcher working, that's more important than leaving it totally broken.

I would like to add that if I click on the application launcher, I am giving it focus. So it should open.

Focus stealing prevention is for preventing stuff you didn't click on from getting focused. But I explicitly click on something, then that means I do want it to get focus.

Preventing something I explicitly click on from getting focus does not make much sense.

(In reply to Nikos Chantziaras from comment #4)
> I would like to add that if I click on the application launcher, I am giving
> it focus. So it should open.

No you don't. You click the panel (which is a window) which opens another window. Passing focus to that is disallowed by your setting.

Specify a window specific rule to exclude Plasma from that level.

Setting back to worksforme - from window manager side there is nothing to do. The feature works exactly as advertised.

Brilliant.

Very smart design choices by the KDE team. You have my congratulations. We need more people like you.

But you know what? I'm going to reopen this bug, simply because you're wrong.

Nikos, I understand that you're frustrated, but please refrain from using sarcasm and insults. That's a sure way to get people to ignore you, even when you're right.

Martin, I feel that you're being a bit inflexible here. If this feature is behaving as expected, then the expectation is incorrect. Activating a feature should not break another feature and require a user-initiated manual workaround to restore the broken functionality. The user should not need to understand the implementation in order to have a working Application Launcher with focus stealing prevention set to High or above.

For your information I forwarded this bug to the KDE community working group.

You can reopen the bug as often as you won't, but I'm out of here. This bug won't be fixed because I won't do it and after this experience here I would even veto a bug fix. Well done!

Let's not let our tempers get in the way of creating incredible software for the world. We've all got the same goals here!

I'm going to finally reset the status again and I'm urging to not change it again.

In exchange I'm going to explain in more detail.

First of all let's have a look at what the help provides: "New windows get activated only if no window is currently active or if they belong to the currently active application. This setting is probably not really usable when not using mouse focus policy."

We can see here that the help already restricts the usefulness of this setting.

Now let's look at it from a pure window manager perspective: The panel is not the active application, in fact the panel is marked to never gain focus. When clicking the app launcher a new window opens. It's a window just like any other window. The window manager does not know that it is an app launcher. We currently have a window activated and it's not Plasma, so the window won't get focus and won't activate. Which in turn results in the app launcher closing directly as it closes when losing focus.

As I said in a previous comment: this works exactly as advertised! This is obviously an advance feature where we expect users to have knowledge about it. I'm now going to quote KWin's mission statement:
"KWin is an easy to use, but flexible, composited Window Manger for Xorg windowing systems on Linux. Its primary usage is in conjunction with a Desktop Shell (e.g. KDE Plasma Desktop). KWin is designed to go out of the way; users should not notice that they use a window manager at all. Nevertheless KWin provides a steep learning curve for advanced features, which are available, if they do not conflict with the primary mission. KWin does not have a dedicated targeted user group, but follows the targeted user group of the Desktop Shell using KWin as it's Window Manager. "

This setting is an advanced feature, we expect the user to have an understanding of the feature when using it. We expect the user to understand that this feature does not work with other elements in a perfect way - this is even documented!

Now I understand that this is all fine, but when using a desktop this should work. But for the desktop it's the same. Our tagline is "simple by default, powerful when needed". By default all of this is working, the app launcher opens, it gets focus. But Plasma let's you adjust the window manager, you can set an advanced feature giving you the powerful when needed. Things might not work as expected, but again Plasma gives you the features to help yourself. With a simple window rule you can fine tune that the app launcher gets focus. It is powerful when needed!

So is this here a bug? From KWin perspective: no, everything works as expected. Fixing it without breaking the focus stealing prevention is nearly impossible.

From an overall system perspective: maybe, but we are in the advanced feature section and there is a good and simple workaround. So overall this is a clear worksforme.

A reminder of our Code of Conduct [1], which states: 

"Be respectful
In order for the KDE community to stay healthy its members must feel comfortable and accepted. Treating one another with respect is absolutely necessary for this. In a disagreement, in the first instance assume that people mean well."

I would ask that all participants in what has become a debate: step back, reconsider, and in some days if necessary, think together about how to deal with this issue.

Valorie, for the Community Working Group

1. https://www.kde.org/code-of-conduct/

So how on earth do I prevent applications from stealing the focus? They do it all the time on "medium".

When I work on MS Windows, all applications are blocked from stealing focus from the currently active application. Under KDE, they are allowed to pop-up their windows wherever they want.

"Medium" is useless. So now you're saying "High" is also useless.

What can I say to that other than it's a mess that needs fixing?

So this is a request for fixing it.

@Nikos: if Windows works better for you consider using it.

Why are you trying to trigger me all the time? First with arrogance, then with this.

Do you have something against me? I assure you this is nothing personal.

This is the final time that I mark this bug as works for me. If you reopen again, I will make sure that you cannot reopen again!

Martin, you're being really rude. Having this kind of experience is the sort of thing that turns people off a project for good.

Here is the thing, folks. When a maintainer closes a bug report, users should not open that bug report again, whether they feel that their point is valid, or not. Maintainers are responsible for bug reports against the components they maintain and whether rightly or wrongly, are the final arbiters. ALL users of bugs.kde.org as well as other parts of the KDE infrastructure -- including maintainers -- are responsible for following and supporting the KDE Code of Conduct. Technical disagreements should focus on technical details, without strong language, sarcasm, name-calling or other disparagement. We all want a strong community and awesome software.

With the same maintainer closing another bugs and claiming "it's a feature", it's kind of difficult to not get mad at that person:

https://bugs.kde.org/show_bug.cgi?id=377913

> We all want a strong community and awesome software.

That's difficult if bugs are presented as "features." We will never have awesome software.

I have to say that I agree that this is in fact a bug. Focus stealing prevention is about application windows from a conceptual level to our users, and while Martin is technically correct that the shell are also windows, this behavior is not at all what the user expects from this option. The option applies to application windows (which is correct both from a user POV and from a technical POV), but it should not apply to things like the kickoff menu (there it's only technically correct, but not from a user POV).

What should be fixed here is that the option should probably exclude desktop windows by default (as to not break the user experience without a big fat warning). We're just making it unnecessarily hard to use this option, arguing that this is "technically correct" is completely ignoring our mission to create something that gets out of the way for users. We can't expect users to understand why this breaks and how to fix this, we should do the sane thing and not break Plasma by default.

@sebas: but kickoff is not even marked in any way as a desktop window. We don't have the information. That's the same as focus (strictly) under mouse doesn't work with kickoff and that kickoff does not work properly with focus follows mouse. There we always said that it's fine.

For me, Kickoff works just fine with Focus Follows Mouse as well as Focus Strictly Under Mouse.

I agree with Sebastian. We are arguing over technical details that it is unreasonable to expect users to understand, or care about. We should find a way to make this work rather than come up with reasons to justify why it doesn't.

I'm aware that a solution to this problem means marking these windows in some way, not a biggie in my opinion, but maybe the most straightforward fix is to mark these windows as belonging to the shell and then allowing them to steal focus?

From a purely technical perspective, Martin is right: This is not a technical bug, because it works exactly as he has designed it.

However, that does not keep it from being a massive usability problem. 
Sure, from a technical perspective, a popup from an application launcher is a new window, but not from a user's perspective.
From a user perspective, it's really just "I click this button, and then that button spawns a popup as a natural reaction to my click". The popup is an extension to the button, not a separate window that just happens to be spawned by the button.

If a user has an expectation towards the system but the system behaves differently, then from a user perspective it's broken. Users don't care about what is technically correct, and they should not have to.

Martin, you say that focus-stealing prevention is an advanced feature. You are certainly right, but I am very certain that there are lots of users out there who are advanced enough to want to use focus-stealing prevention, but not advanced enough to understand why that keeps the launcher popup from opening. The latter knowledge is extremely advanced, as it requires in-depth knowledge of window management.

So yes, it WORKSFORYOU, but only because you have knowledge that the vast majority of users - including those who are advanced enough to want to use focus-stealing prevention - don't have.

From a social perspective: I don't approve of people reopening bugs that the maintainer has closed (unless new information has emerged, which was not the case here), and I do not approve of sarcasm in bug reports either.

On the other hand, I do not approve of punishing all users with refusal to fix a usability problem because a few users behaved inappropriately in a bug report, either. I do not think this is fair towards the other users who have never misbehaved but would be stuck with a usability problem, anyway.

@Thomas: there simply is no usability problem here. This feature exists for > 10 years (which also means I did not design or implement it) and works with the constraints for the same time. This must have been broken with Kicker as well (yes I talk of KDE 3 here). This is the first bug report for this problem. To me it means it is not a problem which users will hit likely.

This means it also doesn't make sense to invest time into it. Sorry, but we have more important things to fix. Lots of them.

I can offer some solutions:
1) remove focus stealing prevention HIGH and EXTREME. Reasoning: we are not able to make it work in a Plasma session and don't have the expertise to maintain it
2) We remove the GUI setting and make it an advanced option
3) We show a warning that this breaks Plasma panels if selected

If I would have to pick one I would go for 3 as we do that in other places as well.

For example if you want to use "Focus Under Mouse" it says that Alt+Tab cannot work. Or the Compositor settings show a warning when selecting any of the "dangerous" settings.

Please note that I marked the bug as WORKSFORME before we had misbehaving in this bug report. There is no punishment going on.

This isn't the first report of this kind of problem -- see 352647.

At least from my perspective, "new windows get activated only if no window is currently active or if they belong to the currently active application" should mean "the panel is active, and the application launcher is a child of it, so it gets focus".  Never mind that the panel may not formally be a window; it certainly looks like one and otherwise acts like one.

The limitation of not being usable without a mouse focus policy is irrelevant to me, and no doubt many others.  I always use mouse focus.  I'm from the old days of X10 (yep, the predecessor to X11), and the only window manager of the time, xwm, was what we'd call focus strictly under mouse.  I don't particularly work in the paradigm of staying concentrated on one thing for a while, then switching neatly to something else.  I'm a lot more chaotic in my working style, constantly zipping back and forth between things, but I want that to be under *my* control, rather than that of whatever application decides to pop a window.

Focus stealing prevention is really, really important.  As it stands, even at high it *still* isn't perfect; there are situations where a LibreOffice window on another virtual desktop no less will grab focus.  This is problematic, since I have at least one document where some things take several minutes to run (in particular, I have a spreadsheet that's so big and complex that merely editing an alias (name) or saving the document takes multiple minutes, and at a few points along the way LibreOffice decides to help itself to the focus, which on a few occasions has resulted in stray keystrokes going to it).  Medium is useless; way too many steals get through.

Is it possible to write an exception rule to the effect of "all windows created by a click on the panel or by a right mouse click on the desktop, get focus"?

> Is it possible to write an exception rule to the effect of "all windows created by a click on the panel or by a right mouse click on the desktop, get focus"?

As I mentioned a few times in this bug report: create a window specific rule for plasma to bypass focus stealing prevention.

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

> As I mentioned a few times in this bug report: create a window specific rule for plasma to bypass focus stealing prevention.

I think the objection here is that it doesn't seem reasonable to require that the user do this manually (and know that they have to, and know how to do it...) just to make the focus stealing prevention feature work the way a typical user who is not a KWin developer would expect it to work.

If this could be implemented by providing a window-specific rule, perhaps the bug could be fixed by distributing that rule with either the Plasma or kwin base package.  But it needs to apply to anything -- application launcher, menu, what have you -- triggered by interacting with the panel.

The current behavior makes absolutely no sense from a user standpoint.  If I click on the browser menu bar, a menu pops up regardless of the FSP.  Interacting with the panel is, from my perspective, _exactly the same operation_.  In reference comment 12, *the panel is the "currently active application"*.  Maybe it's not _implemented_ that way, but from a user perspective, that's what it is.

I don't care if this isn't usable with click to focus.  I don't know offhand why it isn't, but I don't particularly care per se; I use focus follows mouse - mouse precedence (with both click raises active window and raise on hover disabled, if that makes any difference).

I absolutely need focus stealing prevention.  To be quite honest, even high isn't high enough.  There are still cases where firefox (when it starts up) and LibreOffice (at various times when a file is being saved or a computation is in progress -- as I said, I have a spreadsheet where those can take minutes, and yes I used the wrong tool, and no I'm not going to rewrite it as a database app any time soon) grabs the focus, and whatever I'm typing goes into it.

My login procedure prompts for a number of passwords.  Firefox takes its time coming up (the problem with a ridiculous number of extensions and tabs, but foo), and at some point in the whole process, pops itself on top of those password prompts and helps itself to the focus.

Why does FF do this?  Why does LO do this?  BTHOOM.  I don't know why; all I know is that I don't want it to do that.  Extreme FSP would likely put a stop to it, but at the cost of making the panel entirely unusable.  I suppose I could learn how the rules work (if I could figure out what "window classes" are and such) and write a bunch, but I'm not a window management expert and have rather less than ardent desire to become one.  I rather doubt that I'm the only user who has this problem, and the comments here confirm that.

This still isn't fixed in KWin 5.12.5 and it needs to be fixed. Call me an idiot user, but I had this problem for months before I realized what caused the problem, had my bug report finally ready to submit when I spotted this bug under "Possible Duplicates". No amount of mental gymnastics ("technically" this is not a bug) can justify leaving the user with this broken behavior as it is, which is not even consistent: the activity management widget is not suppressed by stealing prevention High, and once it is open, I can also open the Application Menu and Weather Widget. A simple warning in the setting dialog would actually be good enough for a fix. I have lost all hope for a well working focus stealing prevention anyway.

This seems to be only a problem on X. Is focus stealing prevention on Wayland not yet implemented or is there another reason for that?

Just to add my experience as a user (since 2003). I've encountered the same exact issue and have had the same thoughts or very similar as those expecting "high" be "extreme". Pressing "alt f2" and seeing the window close before it can even really open is unexpected behaviour, for me too.

In a note of humor, and I hope there's still some left here; I'm afraid to try the option called "extreme" (I will try it on a computer I'm willing to re-install).
: ]

Thanks to the KDE team for making a libre desktop so good we're willing to get angry about it.

(In reply to Roman Gilg from comment #33)
> This seems to be only a problem on X. Is focus stealing prevention on
> Wayland not yet implemented or is there another reason for that?

Focus stealing prevention is not yet implemented.

Resetting to wontfix. Just reopening won't change anything. The analysis of the situation in comment #1 still holds. This is not a problem of the window manager. It works exactly as intended. Any changes would require X11 specific feature additions and KWin is feature frozen for changes on X11.

Please do not reopen. This bug won't be fixed.

(In reply to Martin Flöser from comment #12)
> First of all let's have a look at what the help provides: "New windows get
> activated only if no window is currently active or if they belong to the
> currently active application. [...]"
> [...]
> Now let's look at it from a pure window manager perspective: The panel is
> not the active application, in fact the panel is marked to never gain focus.
> When clicking the app launcher a new window opens. It's a window just like
> any other window. The window manager does not know that it is an app
> launcher. We currently have a window activated and it's not Plasma, so the
> window won't get focus and won't activate. Which in turn results in the app
> launcher closing directly as it closes when losing focus.
Is the panel I intact with being unfocused relevant to the problem of the app launcher not getting the focus? In other words, if the panel was focused, would it be allowed to pass the focus to the app launcher?

If so, is the panel never getting the focus the actual bug here?

The behavior may be correct according to the spec and the implementation of the panel (as a window that never gets focus), but it's completely nonsensical from a user perspective to have core functionality (application launcher or application menu won't work when focus stealing prevention is enabled).  It may meet the letter of the UI spec, but if that's the case the spec is flawed from a user experience perspective.

(Incidentally, one workaround is to use focus under mouse or focus strictly under mouse, but those have their own problems and I believe they are considered "unreasonable".  The other workaround, with focus follows mouse/mouse precedence)

The question I wish to ask the development team is "how can the user avoid getting new windows popped up over existing work or otherwise stealing focus away from whatever the user happens to be doing, without losing the ability to use the application menu or application launcher?"  If the answer is in fact "there is no way to get both", then something's very wrong.  The app menu is basic KDE functionality; not having windows pop up over what you're doing is a thoroughly rational thing to want (you don't want to be entering a password and something suddenly grabs focus, and you don't want to be typing C-a C-x C-s in emacs (which keystrokes mean "go to the beginning of the line (C-a)" and save (C-xC-s), only to have something suddenly grab focus, interpret it as select the entire document, cut it all, and save.

If the answer is "write a window specific rule to do this", that's OK *IF* that rule, along with other similar rules needed to achieve rational (from a human non-developer perspective), is present by default.  There's nothing fundamentally wrong with implementing behaviors as rules within the confines of the system; that can have the advantage of being easier to change than something hard-coded.  Put another way, would you accept a (hypothetical) pull request for an addition of said rule?

But expecting ordinary users to understand "window-specific rules", and what constitutes a plasma dialog and how to describe it within those rules, is simply not in my view a reasonable expectation.  It requires them to have deep knowledge of how window systems work, which if one is not a developer of window systems, is not something most people care to have to learn.

In summary, while the behavior may meet the specification (and "resolved/won't fix" therefore being technically correct), there's still a major problem here that by all evidence (the number of people commenting on this bug, all saying essentially the same thing) is a very strong indication that something is wrong here.

(In reply to Theo from comment #37)
> (In reply to Martin Flöser from comment #12)
> > First of all let's have a look at what the help provides: "New windows get
> > activated only if no window is currently active or if they belong to the
> > currently active application. [...]"
> > [...]
> > Now let's look at it from a pure window manager perspective: The panel is
> > not the active application, in fact the panel is marked to never gain focus.
> > When clicking the app launcher a new window opens. It's a window just like
> > any other window. The window manager does not know that it is an app
> > launcher. We currently have a window activated and it's not Plasma, so the
> > window won't get focus and won't activate. Which in turn results in the app
> > launcher closing directly as it closes when losing focus.
> Is the panel I intact with being unfocused relevant to the problem of the
> app launcher not getting the focus? In other words, if the panel was
> focused, would it be allowed to pass the focus to the app launcher?
> 
> If so, is the panel never getting the focus the actual bug here?

No, a panel is not supposed to get focus

Dear users, let me please explain once more. I totally understand that you consider this as a bug. But from the window manager perspective this is not a bug, but the expected behavior. Thus a change is considered a new feature and not a bug fix.

For new features KWin has quite strict rules:
 * no new features for X11
 * no workarounds for incorrectly behaving applications
 * no advanced features which can already be achieved with existing advanced features such as KWin rules or KWin scripting

In this case all of these points hold. It is an X11 specific feature, which is needed to workaround broken applications and the wished feature can be accomplished by KWin rules.

Thus from the window manager perspective this feature get evaluated as a wontfix. I think it is the most honest thing we can do to mark a feature request as wontfix if it is obvious that we won't implement it.

I totally understand that you want this feature and that you are disappointed that it won't be added. I also understand that you consider it as a bug and that you don't care that I only look at the window manager side but at the big picture. Please note that while KWin is developed for Plasma, it's not it's only use case and the KWin development team always sees Plasma just as yet another client. No workarounds are added for Plasma, we follow there the strict rule of no workarounds for clients. This is based on experience where we had decade old useless checks affecting all users negatively. 

I need to point out that anybody is able to create the required window rule or script and distribute it through store.kde.org. KWin does not ship additional rules or scripts. We expect our users to do it. We provided the functionality for users to adjust KWin to exactly their needs. If they want focus stealing prevention and some windows to pass it: we added the functionality. But we won't ship such rules for workarounds of advanced features.

I hope you understand that this won't be changed and I hope that the discussion here stops now. Further discussion won't help.

(In reply to Martin Flöser from comment #39)
> (In reply to Theo from comment #37)
> > Is the panel I intact with being unfocused relevant to the problem of the
> > app launcher not getting the focus? In other words, if the panel was
> > focused, would it be allowed to pass the focus to the app launcher?
Does anybody know the answer to this question?

> > If so, is the panel never getting the focus the actual bug here?
> 
> No, a panel is not supposed to get focus
That looks to me like a "window specific rule" that ships with the panel widget, and which is unexpected by users who direct their "focus" on the panel when they click the app launcher button. I understand that this is not a KWin question, but the curt reply makes me think a simply minded user like me is obviously not supposed to understand the infinitive wisdom behind this behavior of the panel.

Comment #40 really makes my blood boil.  Reduced to its essentials, "it doesn't matter how much pain it's causing the users, the rules come first".

I will admit that there are times when the rules are there for a good reason, and they actually do benefit the end users even if that's not recognized.  For example, a 2 factor authentication app I use does not allow backing up or restoring tokens to a device.  That's generating a number of user complaints, but it's actually the right thing: being able to back up and restore tokens would allow cloning the token, violating a basic assumption behind two factor authentication, that the token is unique and allowing a big security hole.

There are also times when a fix might simply be too costly in engineering resources (perhaps preventing fixing more critical issues) or where a seemingly simple fix would have non-obvious consequences that would result in even more difficulty.

As best as I can determine, though, none of these circumstances apply.  There's no security (or other critical, from a product standpoint) hole that this would open (quite the reverse, actually); there is an easy fix (a window-specific rule), and there are no consequences (e. g. unexpected bad behavior) that would result from this change.  The reasoning is presented solely in terms of project rules and the desire to maintain perfect consistency with said.

If there are unexpected consequences, I invite Martin to present them.  I recall a discussion I had on another window management issue I was having with focus stealing prevention and focus under/strictly under mouse, where the assignee of the bug explained why focus stealing prevention inherently is not compatible with focus strictly under mouse, and the simple expedient of using focus follows mouse (which isn't quite what I want -- I also want a window to lose focus if I move the mouse outside it -- but it's seemingly close enough).  I wasn't too thrilled, but I received an explanation of why what appeared to me to be straightforward actually wasn't what I thought it was.

But this response is quite different -- it refers solely to strict internal project rules, and makes no attempt to demonstrate any unexpected user harm or even to note particular difficulty in implementing a fix.  That's simply not a satisfactory answer.

It would be great if users would not do any assumptions on the complexity of a change. Shipping a window rule obviously does not solve the issue. Shipping a window rule would affect all users whether they use the focus stealing prevention or not. It would mean that any plasma window would get focus no matter how other windows are currently active. This might not be what all users want. So we would replace one problem with another one. Thus window rule as general solution for this problem is not possible. It's a good solution for users, but not for general.

That means a code solution is required involving identifying Application launchers (KWin has no idea what an application launcher is), making it robust, so that other applications cannot abuse and all of that at the same time without hardcoding anywhere "plasma", because Plasma might not be the only desktop shell ever used with KWin. This is in the range of impossible. I don't see a solution on how to allow one application to bypass focus stealing prevention without opening a backdoor for other applications. As we can see from this, such a change would have security implications, it's rather complex, it would most likely have side-effects. So given that it qualifies in all of the points you mention as valid.

But all of that doesn't matter to me. For me the only thing I decide on is: is this an X11 specific feature, if yes, then it won't be added. This is obviously the case here as it requires a new X11 specific protocol to announce application launchers to the window manager. Thus it won't be implemented due to the feature freeze.

But even if there were no rules, it is unlikely that this would be fixed as I don't see how to implement it. Thus it would just stay open forever. No screaming here makes a window manager impossible task, possible. So I urge anyone to calm down, write the window rule and be happy.

Thank you for the explanation.  Providing that up front would have saved a lot of headaches.  It wouldn't have solved the immediate problem, but it at least would have given useful background.  It does, however, raise two more questions:

1) Why can the panel never receive focus (which by the sound of it would have largely solved the problem)?

2) A bit off topic, but how does Wayland deal with the issue of applications trying to grab focus?

In addition to the one I asked but did not receive an answer to, namely what do other people do if they don't want windows popping up randomly on top of what they're working on?  Or is that really such a rare situation?

So interestingly enough if I click on the device notifier icon its window *does* pop up.  So what's the difference between the device notifier and the application menu?

Is the problem perhaps that the application launcher is assuming that it gets focus immediately, and pops down when it doesn't get it?

If so, it sounds like the problem is with the application launcher, not the window manager and the WM is behaving completely correctly, and that's where I should file a bug.

(In reply to rlk from comment #45)
> So interestingly enough if I click on the device notifier icon its window
> *does* pop up.  So what's the difference between the device notifier and the
> application menu?

the difference is probably that the device notifier does not try to get activated and that it doesn't close on focus lost.

(In reply to rlk from comment #45)
> So interestingly enough if I click on the device notifier icon its window
> *does* pop up.  So what's the difference between the device notifier and the
> application menu?

It gets more interesting. When I click first on the activity manager widget, which also works, and then on the app launcher, the app launcher will not be suppressed. Or the app launcher might be working just fine after I have restarted plasmashell... This erratic behavior made me think for months that this is just another quirk of the buggy plasmashell and not some interference with an incompatible setting.

(In reply to Theo from comment #48)
> It gets more interesting. When I click first on the activity manager widget,
> which also works, and then on the app launcher, the app launcher will not be
> suppressed. Or the app launcher might be working just fine after I have
> restarted plasmashell... This erratic behavior made me think for months that
> this is just another quirk of the buggy plasmashell and not some
> interference with an incompatible setting.

In high focus stealing prevention mode, if you remove focus from any window (e. g. by clicking on the desktop), it pops up.  I suspect this is the situation you're finding.  In extreme focus stealing prevention mode, even that doesn't work.

Reference bug 394934.

From https://bugs.kde.org/show_bug.cgi?id=409610#c1:

"[...] the argument that "kwin works as intended" and closing it is embarrassingly ridiculous and doesn't solve the problem [...]"

Re-opening. Surely we can come up with a solution here, since we control both KWin and Plasma.

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

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

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

i'm puzzled that the focus of this discussion has been on kwin.  isn't this a launcher issue?  The launcher gets invoked, by mouse or by keyboard, and it may or may not get focus.  Seems to me it ought to be fine whether or not it receives focus, and it should stay up and wait for further interaction.  if it both receives and then loses focus, then it should roll down.

i'd advocate reassigning this bug and fixing the launcher accordingly, and i'm grateful this thread has suggested meanwhile i might still get by with extreme focus stealing protection if i merely defocus the active window before invoking the launcher.

Of course it gets more interesting with high or extreme focus stealing prevention.  Even if the launcher arrives underneath the currently active window, at least part of the launcher ought to be visible over the panel.  But if the active window is fullscreen and covers the panel then yeah the launcher would roll up but remain invisible.  Still that sounds reasonable in that circumstance.  Perhaps it could just roll up on a different screen if there are other screens, but i'm not begging for that, just suggesting.

i'm also perplexed that more folks don't demand strong focus stealing protection.  is it truly such a minority of us that are frustrated by popups that steal keystrokes from ongoing typing which rapidly dismisses them leaving me wondering what that was and what it's going to do next?  More likely it's only a minority of folks that both understand what's possible and bother to contribute their experience.  Focus protection was one of several strong reasons i was a twm fan for many years, tho now firefox no longer plays well with it.  Tho come to think of it the way firefox no longer plays well with it is a highly similar issue, a firefox popup will invisibly appear underneath the active firefox window.  Anyway among the alternatives KDE so far seems to me the most capable while still minimal and welcoming, fiery personalities notwithstanding.

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

I can confirm that this bug still exists at 30th of September 2023. 

The Launcher does not open even with Meta/Super/Windows - key - if ANY of applications is opened.

The only situation when App Launcher opens is when all of the applications are closed/ minimized to panel.

I think this is a really harming bug. For example I re-insalled the whole OS and WHEN EVEN that did not help I accidentally found this bug report. Something like This should not be happening.

I recommend removing the options for Focus Stealing Prevention set to High or Extreme in System Settings.
As it's obvious with this bug - they are un-usable anyway.

Kubuntu 23.04
Plasma 5.27.4
Frameworks 5.104.0
Qt 5.15.8
X11 Window System

(In reply to Sami Saarinen from comment #57)
> I can confirm that this bug still exists at 30th of September 2023. 
> 
> The Launcher does not open even with Meta/Super/Windows - key - if ANY of
> applications is opened.
> 
> The only situation when App Launcher opens is when all of the applications
> are closed/ minimized to panel.
> 
> I think this is a really harming bug. For example I re-insalled the whole OS
> and WHEN EVEN that did not help I accidentally found this bug report.
> Something like This should not be happening.
> 
> I recommend removing the options for Focus Stealing Prevention set to High
> or Extreme in System Settings.
> As it's obvious with this bug - they are un-usable anyway.
> 
> Kubuntu 23.04
> Plasma 5.27.4
> Frameworks 5.104.0
> Qt 5.15.8
> X11 Window System

After reading Martin Flöser's comment I understand his point of view.

This feature may be needed in special environments - like factory automation control - but for a basic home user this feature is potentially "dangerous" - as it is in the middle of non-critical settings.

I suggest High and Extreme Focus Stealing Prevention should be separated from other focus stealing options - and clearly marked as "For Advanced Users Only - Be aware what you are doing before selecting these options ".

@Nate

Martin Flöser offered three possible solutions in his comment 26  . None of these have been implemented at September 2023.
Please select one of his options - as the current situation for everyday user is harmful. 

"I can offer some solutions:
1) remove focus stealing prevention HIGH and EXTREME. Reasoning: we are not able to make it work in a Plasma session and don't have the expertise to maintain it
2) We remove the GUI setting and make it an advanced option
3) We show a warning that this breaks Plasma panels if selected

If I would have to pick one I would go for 3 as we do that in other places as well.

For example if you want to use "Focus Under Mouse" it says that Alt+Tab cannot work. Or the Compositor settings show a warning when selecting any of the "dangerous" settings."

FSP High works just fine for me either with the super key or with the KDE button.  It may or may not be relevant that I use focus follows mouse (mouse precedence).  The documentation for High FSP does state "This setting is probably not really usable when not using mouse focus policy".

I'd really like Extreme to work correctly; I absolutely do not want windows popping up and grabbing focus (think about what happens if I'm in the middle of entering a password -- this does happen even in High FSP when I'm entering the kwallet password and something pops up and grabs focus away).  What doesn't make sense is for individual users to be responsible for writing rules that are necessary for KDE components to function correctly; that's something that I think KDE should provide itself.