Bug 364689

Summary:	Prevent/delay focus stealing while typing
Product:	[Plasma] kwin	Reporter:	ned <naught101>
Component:	rules	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	REPORTED ---
Severity:	wishlist	CC:	andy, b7.10110111, bugseforuns, Deckweiss75, rnet723, timucinbahsi, unblended_icing552
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=458978
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description ned 2016-06-24 05:54:31 UTC

I have focus stealing prevention turned off, generally, because I like to be notified if something requires my attention (e.g. password inputs, chat messages etc). However, when multiple things are happening at once, it can happen that you're half way through typing something, focus is stolen, and you end up typing the rest in the wrong window. This can be problematic at times: for example, accidentally pressing the wrong ok/cancel button in a new dialogue window, or accidentally sexting your grandmother...

It would be great if there was an option to turn focus stealing prevention on only while typing - so, for example, if I press any key, focus stealing is prevented for the next 1000ms (configurable). It would be ideal if focus stealing was optionally delayed, instead of prevented: so one second after I stop typing, and I'm looking at the screen, thinking, and the new window pops up, and I can react intentionally, instead of accidentally.

Reproducible: Always

Comment 1 Thomas Lübking 2016-06-24 06:02:32 UTC

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

Comment 2 ned 2016-06-24 06:22:29 UTC

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.

Comment 3 Thomas Lübking 2016-06-24 06:35:00 UTC

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

Comment 4 Patrick Silva 2022-12-08 11:05:17 UTC

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

Comment 5 timucinbahsi 2022-12-29 12:09:50 UTC

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.

Comment 6 Patrick Silva 2023-07-18 20:53:56 UTC

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

Comment 7 unblended_icing552 2024-02-10 10:05:35 UTC

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.

Comment 8 Deckweiss75 2024-06-26 12:05:32 UTC

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)

Comment 9 Deckweiss75 2024-11-25 13:41:57 UTC

Any news? I still have the same issue.

Comment 10 andy 2025-01-01 00:51:09 UTC

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)