I set focus stealing prevention to high, so that, for example, when I click a web link in my email client my browser does not take over the focus. I want links to get opened in new tabs in background. But when I enable that setting, the application launcher that I have in a panel (configured as Always Visible = yes, Auto Hide = no, Windows Can Cover = no, Windows Go Below = no) becomes effectively useless. When I click the application launcher there is no application menu unless I minimize or close all windows. In other words, if there is a window in the place where the menu should appear, then the menu is below that window and it gets no focus. I think that the technical problem could be that the application launcher widget and the menu could be considered different applications and, thus, the focus stealing prevention does not allow the menu to grab the focus. But, in my opinion, they are the same "thing" logically and the menu must always be shown when the widget is clicked. This report is probably a duplicate of bug 377914, but that bug argued that the problem is a bug in kwin and that argument went nowhere.
It is a dupe. But the argument that "kwin works as intended" and closing it is embarrassingly ridiculous and doesn't solve the problem so I won't just mark it is a dupe. Out of curiosity why do you use focus stealing on high?
For me, explained in https://bugs.kde.org/show_bug.cgi?id=377914#c31 In truth, even High isn't really high enough. As I noted, there are situations in which LibreOffice (on a different virtual desktop, no less) manages to steal focus at FSP=High. That's a problem for me, as I noted; I have a spreadsheet that takes several minutes to save, and at some point when it's about finished saving, LibreOffice manages to steal focus. I *really* do not want to be working on something else and abruptly lose focuse to LibreOffice (and have the spreadsheet I carefully saved be trashed by whatever I happen to be typing at the time). But at Extreme the application menu is completely unusable under any circumstances, which is too far. The underlying assumption seems to be that the user is working on one thing at a time, and when an action is taken that creates a new window, that the window will be created and ready for use quickly enough that the user doesn't want to move on to something else while the window is being created (this is also a bit of an issue for KPhotoAlbum for me, with >300,000 photos under management -- I've done a lot of performance tuning work, but it still takes about 10 seconds to start up). My preferred working style is often to jump back and forth between a lot of different things (yes, I know the human factor arguments against it, but whatever), so I want window actions to happen in the background and not interfere with what I'm doing. For that to work, there must be no focus stealing -- I want windows to have to be activated explicitly, by moving the mouse into them (or using ctrl-shift-A to activate).
This is strictly speaking superfluous, but just to give you a better idea of how I work, I turn off both click to raise and autoraise -- yes, I often want to interact with a window while I have another window partly on top of it. It's a very fluid way of working, but it also means that it's absolutely essential that nothing else be able to grab focus away from what I'm doing.
Re-opened Bug 377914, so marking this as a dupe of it. *** This bug has been marked as a duplicate of bug 377914 ***