https://git.reviewboard.kde.org/r/124130/

Cool. Not exactly sure of the terminology, but that looks to cover most of it. I think it would still be nice to have the option for windows to be activated as well as raised after the delay - otherwise alt+tabbing gets really confusing, and mouse-use is required, which is annoying.

Alt+tab oc. completely bypasses any FSP (so would "tools" like the taskbar)
However, take a close look at the date of submission.

Still an issue 6.5 years later.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.26.80
KDE Frameworks Version: 5.101.0
Qt Version: 5.15.7
Graphics Platform: Wayland

Horrible to see the repo links are dead for a feature more than 6 years of age. If anyone decides to attend to this, besides keypress, mousedown events should also be considered for delay worthy states.

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

Windows and GNOME has this feature by default (GNOME seems to do this a bit of aggressive but in general it's doing more help for me). The lack of focus stealing prevention on a slower machine is more severe as the user might continue working with existing application waiting for the new application to launch.

I've wanted this since I've switched to Linux. (Which I did, because KDE had window rules, while WindowsOS just removed per app focus stealing prevention)

Any news? I still have the same issue.

might be possible with a script today:
- when an input event is detected, set focus stealing prevention to Extreme (probably a with dbus method?)
- when input events stop (input event not detected in last e.g. 100ms), revert focus stealing prevention to previous value (e.g. Low)

Have come back here on two separate occasions to request this feature and found it already requested, this change would go a long way for my sanity

Moving this along so the kwin developers can take a look

(In reply to andy from comment #10)
> might be possible with a script today:
> - when an input event is detected, set focus stealing prevention to Extreme
> (probably a with dbus method?)
> - when input events stop (input event not detected in last e.g. 100ms),
> revert focus stealing prevention to previous value (e.g. Low)

This is my current solution for it. I run this script on autostart. But it has some terminal output so you can run it manually and check whether it works first.

KDE Plasma 6, wayland, libinput.

```
#!/usr/bin/env bash

IDLE_TIMEOUT=0.5

last_event=$(date +%s.%N)
typing=0
echo -ne "\rNot typing "
kwriteconfig6 --notify --file kwinrc --group Windows --key FocusStealingPreventionLevel 2

cleanup() {
  kwriteconfig6 --notify --file kwinrc --group Windows --key FocusStealingPreventionLevel 2
  echo -e "\nRestored FocusStealingPreventionLevel to 2"
  echo ""
}
trap cleanup EXIT

exec 3< <(stdbuf -oL libinput debug-events 2>&1)

while true; do
  if read -r -t 0.01 line <&3; then
    if [[ "$line" == *KEYBOARD_KEY* ]]; then
      last_event=$(date +%s.%N)
      if (( typing == 0 )); then
        typing=1
        echo -ne "\rTyping     "
        kwriteconfig6 --notify --file kwinrc --group Windows --key FocusStealingPreventionLevel 4
      fi
    fi
  else
    now=$(date +%s.%N)
    diff=$(echo "$now - $last_event > $IDLE_TIMEOUT" | bc -l)
    if (( typing == 1 )) && [[ "$diff" == "1" ]]; then
      typing=0
      echo -ne "\rNot typing "
      kwriteconfig6 --notify --file kwinrc --group Windows --key FocusStealingPreventionLevel 1
    fi
    sleep 0.05
  fi
done
```

Preventing new windows from being focused for some time after typing is bound to cause a ton of false positives, I don't think we can ship that sort of thing upstream.

Starting with Plasma 6.5, focus stealing prevention "Medium" should effectively prevent focus stealing on Wayland though, without getting in the way too much, and I'm hoping to make it work well enough to make it the default. Please help test it, and if you find remaining issues with that, please add them to bug 509990

@Deckweiss75 thanks for the script, I've been meaning to try it. How's your experience with it been?

@Zamundaaa What is special about the "Medium" setting in Plasma 6.5? I found these recent posts about XDG_ACTIVATION_TOKEN, but is it correct that will only apply to the Extreme setting?

> A new "Extreme" setting for "Focus Stealing Prevention" in the Window Management settings will force KWin to activate a window if and only if it requests activation with a valid token.

- https://www.neowin.net/news/kde-plasma-prepares-crackdown-on-focus-stealing-window-behavior-under-wayland/

- https://blog.broulik.de/2025/08/on-window-activation/


> Preventing new windows from being focused for some time after typing is bound to cause a ton of false positives, I don't think we can ship that sort of thing upstream.

How about a focus stealing setting that allows new windows to pop up, but make them temporarily greyed-out if immediate input is detected (to indicate focus stealing prevention) and block the input for some timeout.

(In reply to andy from comment #15)
> @Deckweiss75 thanks for the script, I've been meaning to try it. How's your
> experience with it been?

I like it so far. Now there is never a focus steal where half my input goes into a newly popped up window.

I notice a few false positives here and there - where a window I want opens in the background.
when doing META -> typing app name -> pressing enter

But those cases are rarer in my workflow than focus stealing windows and personally I find that less annoying than before.

If anything, I feel like my script does not do enough, because it doesn't pay attention to the mouse. Sometimes windows steal focus while I am actively mousing around in another window and I'd like to prevent that as well.

(In reply to andy from comment #15)
> @Zamundaaa What is special about the "Medium" setting in Plasma 6.5? I found
> these recent posts about XDG_ACTIVATION_TOKEN, but is it correct that will
> only apply to the Extreme setting?
"Medium" relies on activation tokens, but additionally has a few heuristics and workarounds for apps that don't use them properly yet. So it should be much less annoying than "Extreme" (until said apps are fixed, at which point they should work fine either way).

> How about a focus stealing setting that allows new windows to pop up, but
> make them temporarily greyed-out if immediate input is detected (to indicate
> focus stealing prevention) and block the input for some timeout.
My first reaction at least would be that it sounds quite annoying still.

I think the best way to progress with that is to test the existing mechanism, document what's wrong with it and then address the specific cases - fixing apps and adjusting heuristics as needed.