Bug 74546 - High focus stealing prevention problem with independent configure dialogs
Summary: High focus stealing prevention problem with independent configure dialogs
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2004-02-08 10:28 UTC by cb-kde
Modified: 2011-12-10 09:39 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description cb-kde 2004-02-08 10:28:35 UTC
Version:            (using KDE KDE 3.2.0)
Installed from:    Compiled From Sources

The focus stealing prevention description for "high" does not match the actual behaviour.

To reproduce:
Set "Focus follows mouse" focus policy
Set Focus stealing prevention level to high.
Open some application, I use xterm.
Move the focus to the xterm
move the mouse to the corner of the screen
Press Alt-F2 to open the Run Command dialogue (loading any application eg from kicker works)
Focus is stolen

The description of High focus stealing prevention is "New windows get activated only if no window is currently active or if they belong to the currently active application..."

Expected behaviour. Focus stealing behaves as described in the help.
Comment 1 Lubos Lunak 2004-03-02 18:46:51 UTC
Oops, there was an off-by-one error. You should get the behaviour of 'High' after selecting 'Extreme', until a fixed version is available (too late for KDE3.2.1 I'm afraid).
Comment 2 cb-kde 2004-03-03 09:54:10 UTC
Using this work around still has problems. If I set the focus stealing setting to extreme, then open the Configure Konqueror dialogue, that window does not get focus and appears behind the konqueror window. Perhaps that is a konqueror bug? Please advise, I'll open a new bug if so.
Comment 3 Lubos Lunak 2004-03-04 12:04:50 UTC
The Konqueror configure dialog is an independent application, so this is the expected behaviour. Other applications may have similar problems if they create configure dialogs the same way. I can try to find a solution, if possible.
Comment 4 Martin Flöser 2011-12-10 09:39:23 UTC
I assume it is fixed after all those years...