Can KWin prevent windows from raising themselves from their v.desktop to the current v.desktop?

[Duncan]

Frank Steinmetzger posted on Wed, 18 Jan 2023 14:15:08 +0100 as excerpted:

> In which other use case do we not want to auto-raise the window? If,
> say, we double-click an image in Dolphin and want it opened in gimp,
> which sits on another desktop.
> 
> And this made me test it: I opened gimp on Desktop 1, Dolphin on Desktop
> 2, right-clicked an image and selected Open with… Gimp. And voilà: it
> showed the old behaviour: the gimp entry appeared on the taskbar and
> flashed. I clicked on it and was moved to Desktop 1.
> 
> So the problem we have with firefox is either a firefox problem, or the
> setting “Switch to that desktop” didn’t work. And with “Bring window to
> current Virtual Desktop”, the Gimp window has moved Desktop, but was not
> raised to the top. So I suspect a Firefox problem here, not Kwin.

Reading that, seems to me the difference in behavior could be focus-
stealing related.  I'd suggest:

1) Check that neither gimp nor firefox have a kwin window rule affecting 
focus-stealing, and adjust/experiment with it if so.

2) Reexamine your general focus-stealing settings (under window behavior, 
focus); perhaps testing strengthening them a notch or two and see if that 
triggers other unwanted behavior.

3) If necessary (presumably because strengthening the general focus-
stealing prevention setting in #2 triggers other unwanted behavior), 
experiment with a firefox anti-focus-stealing kwin window rule.

General notes on window rule focus rules:

There are two window rule settings affecting this, focus stealing 
prevention, and focus protection, basically the inverse of stealing 
prevention.  Hover over them in the property-add dialog to get 
descriptions.  They interact with each other and the general setting based 
on the window that has focus and the window that's attempting to get it, 
so the extreme case for a single window would be setting one to extreme 
while the other is set to none, but that would of course still interact 
with the setting on the other window.

It is of course possible to set a fairly generic rule by adjusting the 
window match wide enough, thus allowing the "other window" to have a 
window rule matching it as well even when it could be any other app, but 
keep in mind that in my experience, such general rules often require 
possibly multiple specific exception rules as well, since they're 
interfering with behavior as designed.  (As an example, I have a general 
window rule that forces most windows to my default activity, but had to 
set exceptions for plasmashell windows to allow them to still appear on 
the otherwise-blank non-default activity.  Example 2, a rule that sets 
active/inactive opacity, that requires exceptions for various windows 
where that's inappropriate.  Altho in this case that's not much more of a 
bother since they really are exceptions that I want to treat differently, 
so even without the generic rule I'd likely have exception rules for them 
anyway.)  Of course the overall result is a proliferation of window rules 
due to generic rules, exceptions, and in some cases exceptions to 
exceptions.  But ultimately it works and I'm happy with it and that kde/
plasma makes such overrides possible in the first place. =:^)

And a caution:

Consider the possible security side-effects.  As an example, consider a 
browser password dialog (say for firefox's master password, if you have it 
setup).  Often you want it raised so you see it and can enter the 
password, but the browser folks ultimately had to change their behavior a 
bit because bad sites were trying to trigger popups without browser chrome 
and setup to appear just like the default password dialogs, in ordered to 
steal people's passwords.  It's thus worth considering this case if 
interfering with normal browser behavior, in case it might allow a popup 
to mimic too closely the behavior of the password dialog.  (OTOH, my 
settings at least, tend to be customized enough that it'd pretty much take 
someone who already had access to have enough information to properly 
mimic behavior and fool me.  A window that looks like a default Windows 
dialog is going to stick out like a sore thumb!  Unfortunately, based on 
the number of people getting taken which must provide at least enough 
reward for the bad guys to keep trying, many just blindly type and click 
without thinking...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman