This is one of the reasons I added extra text to description of the 'mouse (strictly) under mouse' policies saying that these policies break several other kwin features. With other focus policies it should work fine. I'll leave this report open as wishlist, as maybe it's possible to get focus stealing prevention somehow working even with those policies, but it's hard enough even with reasonable focus policies.

I'd like focus stealing to be complete, even with "focus strictly follows mouse".

For background, I use focus strictly follows mouse, with both auto raise and click raise turned off.  I'd like to have focus stealing entirely disabled, so that the focus is *only* where I choose to move the mouse.  I'm fully aware of what this means, and it's what I want: if I move the mouse into a window that's partially obscured, and start typing, my typing will go into that window, and I may be typing blind.  That's exactly what I want.  Likewise, I don't want pop up windows to grab the focus under any circumstances.  In fact, I'd like windows to pop up *away* from the mouse where possible if the mouse is over a window.  I prefer focus (strictly) under mouse so that I can entirely defocus.

I'm not certain whether this is exactly the same thing, but whenever a window is popped up, the desktop is forcibly switched out from under me to whichever desktop the window pops up on.  In addition, certain windows (such as those spawned by javaws) always seem to get focus whenever I switch into a desktop containing these windows, even though I'm using focus strictly follows mouse.

What it really boils down to is that I simply don't want the focus to ever change except by my action, and I want to be able to have no focus in addition to focus on the window of my choice.

Other than alt-tab (which I never use), what other features are broken by focus (strictly or otherwise) under mouse?

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

"wishlist"?
http://www.codinghorror.com/blog/archives/001011.html
http://en.wikipedia.org/wiki/Focus_stealing -- ``This is considered a major annoyance by most users''
It is a bug.  Brain damage inspired by Microsoft Windows and emulated in KDE.  Setting focus stealing prevention to "extreme" is insufficient in KDE.  There is one and only one reasonable exception:  xv (and similar programs that might need to capture window content via selecting "current"), but even then it should be possible for the program to capture what it needs without stealing  back focus.  If setting prevention to "extreme" is not strong enough, then you have to invent a term to mean "absolutely, positively, never, ever allow any program to steal focus, period.  No exceptions".  That should be strong enough.

I have no problem accepting a patch from somebody smarter than me.

In bug 134339 you stated:

      Focus stealing prevention doesn't work with focus (strictly) under mouse focus policies because of difficulties with these focus policies. A patch is welcome.

What are the difficulties with these focus policies that prevent focus stealing prevention from working?  If it's window manager features like alt-tab and such, that's fine -- I have no problem with those not working.  But please be specific.

``I have no problem accepting a patch from somebody smarter than me.''
I'd hope that somebody more familiar with the code than me could do it without an extreme amount of effort.  After all, how many different functions in the code actually set focus?

   if (focus_policy == DO_NOT_EVEN_THINK_ABOUT_REFOCUSING)
      return;

If it isn't close to that easy, maybe the code needs some reworking.

And, for what it is worth, setting focus with keyboard shortcuts does not make any sense with focus under/follows mouse policies.  Not only would I not complain about them being disabled, I think it would be a bug to have them actually work.  If the mouse controls focus, then perforce the keyboard cannot.

I don't remember anymore, it was a long time ago. In general, focus under mouse policies break normal assumptions about how focus works. For example, the basic rule of focus under mouse is that the window under the mouse is active. If the window under the mouse is to be always the active one, then this rule conflicts with any other rule about which window should be active, such as with focus stealing prevention. I don't remember the details, but it was simply too much work for too little gain.

"too little gain" -- let me explain why I use "focus follows mouse".

When you must click to focus, unless you are careful to hit the title bar, the click is passed to the application and it responds to the click.  More often than not, this perturbs the "current position" in that application.  This can be a great inconvenience.  To avoid that problem, you can use the "alt-tab" method of navigation, but when you have two wide-screen monitors and a half dozen or more windows in each of several desk tops, um, that doesn't work so well either.  So, you're back to mouse selection wherein you have to make sure you get it exactly on the title bar, without touching any functional buttons that may be up there, too.  For me, the gain would not be "too little", other than the fact that there is a monumentally huge learning curve in getting to understand the KWin code.  Thank you for your time and consideration.  Regards - Bruce

I guess I see one problem with focus follows mouse, but it need not apply to focus strictly follows mouse.

If the mouse is over the root window, then with focus follows mouse the focus is delivered to the last window to have focus, while with focus strictly follows mouse (my preference), nothing has focus (or rather, the root window has default focus, but since it doesn't accept keyboard events, that doesn't matter.

Now let's suppose a new window pops up under your mouse; it gets focus by either FFM or FSFM.  If your mouse is over a window, then what should probably happen is that the new window pops under the existing window, so there's no problem, but if the mouse is over the root, it will suddenly get focus.  With FFM, that defeats focus stealing prevention, but with FSFM, it's "stealing" focus that just isn't there to begin with (or you could say that it's "taking", but not "stealing", focus).

I'm willing to live with that particular exception to focus stealing prevention, and with FSFM, it's arguably not even an exception to begin with.

Another possibility would be that newly created windows never get focus *at all* until you perform some specific action to give focus.  For example, moving the mouse into the window (if the mouse is over the window where it popped, you'd move the mouse out and back in), or clicking on the title bar, or explicitly raising the window (which I do with a keystroke -- alt-f1 -- that's explicitly bound to that).

``if the mouse is over the root, it will suddenly get focus.  With FFM, that
  defeats focus stealing prevention''
Yep, true enough.  Also enough of an end-case that I don't really care.  This scenario would not yank me from one desk top to another.  This scenario would not yank my mouse from my current window to another existing window and give it focus.  Those are my crucial gripes.  End cases where exact meaning become fuzzy can go any way and I don't care a lot.  It is the day to day Thunderbird and even emacs yanking me about that I find unacceptable.

``I'm willing to live with that particular exception to focus stealing
  prevention, and with FSFM, it's arguably not even an exception to begin with.''
I think we're pretty much in complete agreement.  We just need to convince someone intimate with the code to improve the focus stealing prevention for mouse-following focus policies.  :)

Can we get the severity bumped up? Its a "brain dead inspired" security flaw!

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

Bug 280051 suggests that this is a bug (that could affect security), not a feature request, and severity should be raised accordingly.

(In reply to comment #14)
> Bug 280051 suggests that this is a bug (that could affect security), not a
> feature request, and severity should be raised accordingly.

I disagree: focus under mouse is a broken concept. Users who use it are aware of the limitations including the fact that focus stealing prevention does not work. If users want to have the functionality of a reasonable focus policy, they have to use one of those.

The only solution I see to fix this "bug" is to remove the unreasonable focus policies.

``focus under mouse is a broken concept''
And I think that clicking a window to set focus *AND THEN PASS THROUGH THE CLICK* is a broken concept.  Furthermore, since my work tasks take me from window to window all the time, I would be continually having to click the window and then adjust current place (reclick) within window -- assuming I can remember where I was.  Over and over and over again.  All day long.

Broken.

FSFM is much better than that, even if some of you think I am wrong to find it more convenient.

> FSFM is much better than that, even if some of you think I am wrong to find it
> more convenient.
If focus follows mouse is working for you, just use it. Focus follows mouse belongs to the 
reasonable focus policies. Only Focus under mouse and focus strictly under mouse are broken 
from the concept.

FTR:
The security issue claim is completely bogus.
What do you think how kglobalaccel (global shortcuts) works?
(Your application has the focus and nevertheless another application can react to keyboard events... just think about it... Run "kcmshell4 keys", try to set "a" as shortcut to anything, now try to enter that char anywhere. A keylogger would just not eat it but pass it on to the client or use XTest to pipe it back into the system when unsure where to drop it)

=> The protection against malware is to not run it.

Now run "pinentry-qt4" and enter "getpin" when it asks what to do.
Next try to trigger any global shortcut, including alt+tab or whatever.
(for the ubuntu users: ctrl+d quits pinentry after you closed the window)

Usually any client can "read" the input to all other clients unless one client actively grabs the keyboard.
At this time the focus state of the window doesn't matter anymore and /this/ is, how secure input in X11 works - not by hoping to have the focus or whatever (what doesn't get you *anything* in this regard)

geee... ;-)

===================

On topic:
i'd say anyone here's precisely asking for "Focus Follows Mouse" (read: "FOLLOWS", not "UNDER") which allows for focus stealing prevention as well as alt+tab and will not pass the focus to a client that randomly shows up under the pointer (what is however different from focus stealing)

A wish to separate focus from raising (ie. allow the client to raise but not pass it the focus alongside the stealing prevention) is iirc pending somewhere else in this bugzilla and not hard to do at all.

============

F(S)UM are rather for old (maybe now rather "dead"?) X11 geeks and perhaps users of window tiling.
Removing them might be a little bold, but since there's plenty of space in that dialog below the setting, there could indeed be a "Don't be stupid - you don't want this!" message. But if I was a ditributor targetting certain kinds of users, i'd just remove them downstream.

Moving away the mouse is worse than anything and -i'd say- no option at all and moving away the window can easily collide with window geometry requests as well as with the requirement to find *some* decent position for the client.

Why can't it be made to work, and why is it a broken concept?

See my suggestion in #10 above: if you can't find somewhere reasonable to put the window that doesn't collide with the existing window, pop it *under* the current window (this would work with both FUM and FFM), or even at the very bottom of the stack altogether (just above the root window).

The two typical issues I have are:

1) At startup, I'm starting a number of things (several xterms, emacs, pidgin, and firefox).  When pidgin starts up, it puts up a password prompt in the center of the screen.  Firefox takes longer to start up, so it pops up over the password prompt.  I either have to take a chance on typing my password before Firefox pops up, move the password prompt to somewhere on the screen I hope firefox won't pop, or wait for firefox to come up before typing my password to pidgin.

2) I have some huge spreadsheets, and LibreOffice takes its time getting started, in any event.  So I want to start that spreadsheet, and while it's getting going, do something else.  It might take 20-30 seconds between clicking the icon and the spreadsheet window even getting created, during which I can't do anything else because the spreadsheet might pop up at any moment.

Did you ever try "focus FOLLOWS mouse" then?

<grin type="sheepish">Thanks, that combined with high focus stealing prevention appears to do exactly what I want (on superficial testing).</grin>

However, there's a comment that "high" focus stealing prevention probably doesn't work with mouse focus policies.  That doesn't appear to be the case, so why is that comment there?

(In reply to comment #21)
> However, there's a comment that "high" focus stealing prevention probably
> doesn't work with mouse focus policies.

Forgive my ignorance: "there" is "where"?

My apologies; it's in the Help for Window Behavior in the KDE Help Center (not to mention that I misread it -- it states "This setting is probably not really usable when >not< using mouse focus policy").  I guess I'm having a bad day :-(

(Now, if I could only figure out how to turn off smooth scroll in the help center; the Konqueror setting doesn't apply to it.  But that's a subject for another bug.)

So FFM has one important problem: if I use keyboard accelerators to raise/lower windows, the focus doesn't change (or it changes to something other than what I expect) when I lower the window under the mouse.  This is a rather serious problem for my working style.

I normally create a stack of xterms (2 or 3, but sometimes more) at the top right of the screen (all 80x72, so they're a strictly coinciding stack of windows).  I typically also have a Firefox and one or more emacs windows scattered about.

I use alt-F2 as my accelerator to lower a window (don't ask why I use that accelerator; I doubt it matters, but just for completeness; alt-F1 is raise, alt-F2 is lower, alt-F3 is minimize, probably from back in the X9 days when xwm was the only window manager).  My expectation is that when I do this the window under the mouse (another xterm) is the one that will receive focus, but instead something else gets the focus.

"of course" - because the focus follows crossing (window borders) events what does not happen.
Otherwise you'd end up with FUM and with the same issues regarding the focus stealing.

KWin could however act differently for events triggered by itself or rather explicitly provide "lower window AND put focus to the window with the cursor above it if using FFM"

atm. you can change the focus chain from "recently used" to "stacking order" what passes the focus to the most top one (in this situation) - i think there's another report with such request (to prefer the cursor position - see bug #159989)

Interesting that we get all this requests on the again atm, seems KDE4 gets adopted by the geeks ;-)

@EVERYONE:
would FFM alongside a 3rd option for the next focus (bug #159989) fit your needs?
("so that we can close this bug, spend more time on the other, write a patch and get it fixed")

Seriously: afaics focus UNDER mouse will never work with any focus stealing protection. Iff you can prove different, that'd be great.

From what I can determine, FFM combined with focus stealing prevention *and a change to the focus chain to pass focus to the window immediately under the mouse* would work for me.  The special case of "Kwin could however act differently for events triggered by itself" would not be sufficient: when a window closes of its own accord (e. g. by exiting from an xterm), I want the focus to pass to the window under the mouse (and if that's the root window, focus should pass to the root window).

This suggests a policy of "focus strictly follows mouse", which would probably be what I want.

The workarounds described in 159989 (use either autoraise or click to raise) are specifically *not* acceptable to me.

By the way, my usage pattern has no concept of "recently used" window.  I don't use alt-tab navigation between windows, so I don't want the window manager selecting some arbitary window to receive focus.

And, for more completeness, here's my usage pattern:

I have lots of windows open that are all highly sensitive to "current position".  Like "rlk", I haven't the foggiest notion of which window may be next-most-recently-used.  I know where my mouse is.  I never, ever, *ever* want focus yanked from where I am working without explicit action on my part.  That little pop-up task manager would be cool for that, if only it did not pop up for windows that are gone and if the "come and see me" window were always flagged with that red star.  It is broken and the subject of other bug reports.

So, don't yank me around.

Another crucial point is that I do not want to perturb windows in order to give it focus.  If I click it, the click gets passed through and current position is trashed.  If I use keyboard shortcuts, I have no control over which window is going to become "in focus".  So, I like moving the mouse and let that be my indicator as to what I want to become in focus.  No need for extra keystrokes.  No clicking and perturbing windows.  Just move the mouse and now that window has focus.  Simple.  Easy.  Clean.  Fast (0.2 second setting).

That's the way I need to work.  I don't really give a hoot what the policy name is.  That is the behavior I need.  My current policy is called "Focus Follows Mouse", only just now learning that there is a distinction between that and "Focus Under Mouse".  A clear warning with a description of the distinction would be helpful for folks without the detailed knowledge that many folks here have.

With all of that said, I must confess that I haven't been yanked about recently the way I was several years ago when I first came upon this bug report.  It is possible (likely?) that some intervening fixes made the situation more bearable.  The main remaining gripe about the situation is that with "extreme focus stealing prevention", many windows pop under and remain hidden because the task bar thingey doesn't necessarily highlight the new window with that little red star.  With that glitch fixed, I think I'd be a happy camper.  (vis-a-vis focus management anyway)

(In reply to comment #28)
> I never, ever, *ever* want focus yanked from where I am working without
> explicit action on my part.

-> FFM, extreme stealing protection (i later read that you tend to agree ;-)

> If I click it, the click gets passed through and current position is trashed.

FTR: You are aware that you can only give it the focus or in addition raise it but NOT pass the click to the client? (kcmshell4 kwinoptions, "window actions")

> It is possible (likely?) that some intervening fixes made the situation more
> bearable.

Since 2008? I don't think so.

> With that glitch fixed, I think I'd be a happy camper.
One could actually use the compositor to (translucently) display the window on top of the stack and then "melt" or at least fade through to it's actual stack position (this is only visual. it would never intercept clicks or affect the focus)

Git commit f7140b7ff0763335d3996ce3e635325d7a25bea7 by Thomas Lübking.
Committed on 22/08/2011 at 13:53.
Pushed by luebking into branch 'master'.

add mouse preference against focus chain

there's currently no GUI config item, use
   kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true
   qdbus org.kde.kwin /KWin reconfigure

BUG: 159989
CCBUG: 80897
FIXED-IN: 4.8

M  +59   -31   kwin/activation.cpp
M  +61   -46   kwin/kcmkwin/kwinoptions/windows.cpp
M  +2    -0    kwin/kcmkwin/kwinoptions/windows.h
M  +2    -0    kwin/options.cpp
M  +1    -1    kwin/options.h
M  +17   -0    kwin/workspace.cpp

http://commits.kde.org/kde-workspace/f7140b7ff0763335d3996ce3e635325d7a25bea7

This is still not working in KDE 4.8.0 (OpenSUSE 12.1 KDE:Distro:Factory, kwin-4.8.0-722.4.x86_64).

If I use meta-F2 (which I've bound to lower window), the active window doesn't always become the one under my mouse.  Sometimes I have to do this a few times to get the incorrect behavior, but as best as I can tell the behavior is the same as in 4.7.4.

I'm attaching my kwinrc.

Created attachment 68358 [details]
kwinrc with KDE 4.8.0

NextFocusPrefersMouse does not appear to work.

Lowering a window does not activate another.
FFM is not FUM, will not be and can not be. If we'd change the behaviour like this, you could immediately forget about focus stealing prevention and just use FUM anyway.

Affected are situations when another window becomes activated because the current one is minimized, closed or you change the desktop or so.

Actually, lowering a window *does* result in a different window being activated with FFM as well as with FUM.  Sometimes that window happens to be the one under the mouse, and sometimes it's a different one.  The problem here is that when I lower a window by means of my keyboard accelerator, even with this latest change sometimes kwin picks a different window to activate.

What I want, in essence, is for windows to not grab the focus unless I make a decision to do so.  So if a window pops itself up, it should not grab the focus (like FFM with high focus stealing prevention), but if I lower a window by means of a keyboard accelerator or something, it should recalculate the current window.

(In reply to comment #34)
> Actually, lowering a window *does* result in a different window being activated
yes, sorry. you're right.

This is the "lower" ./. "toggle raise and lower" situation.

The lower shortcut/mouseop picks the topmost client and activates it - no idea whether this is really sane and how to handle, but the patch and config item deals only with picking the "next" client to activate what this code simply doesn't do.

=> we need to figure what to do when the user lowers a client (for the toggle variant doe not alter focus), but that is a different issue.

It should pick the topmost client *that is under the mouse* to activate.  That may result in the same client staying active, if it is the only one under the mouse.

This is the only behavior that makes sense to me.

That is actually about to change - the history of that lower ./. toggle raise/lower has been sorted out as well (mostly because of the keyboard shortcut, that one will likely change for 4.9)
https://git.reviewboard.kde.org/r/103975/

So no relief for another 6 months? :-(

The current behavior appears objectively wrong to me, at least from a user standpoint.  "Focus under mouse" should have the focus under the mouse whenever possible.  Activating a random (from the perspective of the user) client, that isn't under the mouse, makes no sense whatsoever.

Actually for the "unreasonable" focus policies it's ok to skip that change for even 4.8 since they're also bypassed for the "activateNext" stuff (which the current behavior apparently was derived from) because the focus is supposed to be always mouse driven - we just cannot alter the "regular" behavior (including FFM) w/o introducing a new regression.

Ultimately the lowerClient slot was then abused to get the alt+esc shortcut behavior, common among several systems.

What is alt-esc (sorry, I use accelerators)?

What's the bottom line here?  Can focus under mouse be made to work properly, do we need a new policy that does do the right thing, or what?

the alt+esc shortcut triggers some sort of inverse alt+tab where the current client is deactivated and positioned on the bottom of the stack (no, wasn't aware myself until recently ;-)

To support both, the alt+esc behavior and the former "plain lower" we'll have to introduce a new shortcut, thus new visible string, thus wait for 4.9

The "alt+esc" condition however makes absolutely no sense in the pure mouse drive F(S)UM policies (but does in FFM & CTF) what means it doesn't have to be implemented there at all (so the window is just lowered and the focus stays with the mouse, since this is what F(S)UM is about)

The behavior for lowering the window with the mousebutton will in 4.8.1 be (in general!) to pass the focus to the client under the mouse (which may be the same one) unless the lowered client didn't have the focus anyway.

In addition it's possible and justified to skip that alt+esc shortcut behavior for F(S)UM (and 4.8.1 as well)

For 4.9, the "lower window" shortcut and the "alt+esc inverse tabboxing" shortcut should become distinct - regardless of the focus policy.

Altogether this has however ABSOLUTELY nothing to do with this actual bug being about FUM & focus stealing prevention - that's no gonna work anyway.

----
inb4 "finally": it wasn't that easy to sort out what happened when and (probably) "why" in this regard.

Ah.  I don't use alt-esc (or alt-tab, for that matter).  I have alt-f2 bound to Lower Window (alt-f1 bound to Raise Window, and alt-f3 bound to Minimize Window). This comes from the old X10 xwm behavior.  Using FUM, this only deactivates the window if it results in the mouse being immediately over a different window when it's lowered.  If lowering the window results in the same window being under the mouse, it stays active.

What I want is this behavior combined with focus stealing prevention.  I don't care what it's called.  With FFM, it looks like the behavior is *almost* correct, except for shifting focus to what appears to me to be a random window rather than the one immediately under the mouse.

Git commit 095c602617949afc55e34d0634f8de8357ca28eb by Thomas Lübking.
Committed on 21/02/2012 at 23:55.
Pushed by luebking into branch 'KDE/4.8'.

- lower windows does not change focus for F(S)UM
- lower by shortcut honors nextFocusPrefersMouse setting
REVIEW: 104041

M  +10   -3    kwin/useractions.cpp

http://commits.kde.org/kde-workspace/095c602617949afc55e34d0634f8de8357ca28eb

Don't know all of the details of the code, but that looks right.

I'm closing this bug that initially says "make FSP work with FUM" as won't fix because that cannot fix and the whole thing turned to anything different and nobody can read through all this ;-)

In case there are other issues or suggestions regarding FFM, please check whether such report is already present or head over to the brainstorm section of forum.kde.org (unless you're really sure the behavior is actually a bug and no way intended)

you may also be interested in https://git.reviewboard.kde.org/r/104316/

So it looks like there are a few new policies in 4.11, but they still don't do what I'm looking for.

The one of interest is "Focus follows mouse - mouse precedence" which is described as

"This is mostly the same as Focus Follows Mouse. If an active window has to be chosen by the system (e. g. because the currently active one was closed) the window under the mouse is the preferred candidate. Choose this if you want a hover controlled focus."

What I want is for newly-created windows to be at the top, but to not receive focus until I take action to give it focus (by moving the mouse into them).

If I set focus stealing prevention to medium, new applications that I pop from something else receive focus even though they're not under the mouse.  Say, for example, that I have an xterm window on the right side of my screen, and type "emacs" into it.  The emacs window is created at the left side of the screen, and receives focus.  It should not (by my preference) receive focus.

If I set focus stealing prevention to high, then new applications don't get focus, but in some cases they're left at the bottom, invisible.  Starting emacs from xterm works correctly (the emacs window is at the top of the stack, but does not receive focus).  However, if I launch an application from the KDE menu or from the panel, that application remains hidden at the bottom of the window (presumably I would miss reminder windows that way).  I want it visible, just not receiving focus.

Both of these *almost* do what I want, but in both cases, the things that don't work are severely problematic.

(In reply to comment #46)
> So it looks like there are a few new policies in 4.11, but they still don't
> do what I'm looking for.

Thank you.  You described my preferences perfectly!
1. new windows should always be visible
2. they should never receive focus until the mouse moves into it.

How visible is a "resolved -- won't fix" bug anyway?
Does that mean the KDE project would like us to file another?
One that describes these remaining relatively minor anomalies?

(In reply to comment #46)
> So it looks like there are a few new policies in 4.11
No. Only the GUI got bumped to better reflect available focus policies.

> What I want is for newly-created windows to be at the top, but to not
> receive focus until I take action to give it focus
Unrelated to focus policy. This is matter of focus stealing prevention *only*, not distribution.
The window gets the focus because it asks for it, focus management is possible (in contrast to with F(S)UM) and the stealing prevention is "too low" to prevent it.

What you complain about is simply that focus and layer are tied.

See https://bugs.kde.org/show_bug.cgi?id=110543 and http://forum.kde.org/viewtopic.php?f=83&t=101833 and https://git.reviewboard.kde.org/r/110919/

> If I set focus stealing prevention to medium, new applications that I pop
> from something else receive focus even though they're not under the mouse. 
This has nothing to do with the mouse, see above.

(In reply to comment #46)
> So it looks like there are a few new policies in 4.11
No. Only the GUI got bumped to better reflect available focus policies.

> What I want is for newly-created windows to be at the top, but to not
> receive focus until I take action to give it focus
Unrelated to focus policy. This is matter of focus stealing prevention *only*, not distribution.
The window gets the focus because it asks for it, focus management is possible (in contrast to with F(S)UM) and the stealing prevention is "too low" to prevent it.

What you complain about is simply that focus and layer are tied.

See https://bugs.kde.org/show_bug.cgi?id=110543 and http://forum.kde.org/viewtopic.php?f=83&t=101833 and https://git.reviewboard.kde.org/r/110919/

> If I set focus stealing prevention to medium, new applications that I pop
> from something else receive focus even though they're not under the mouse. 
This has nothing to do with the mouse, see above.

(In reply to comment #47)

> How visible is a "resolved -- won't fix" bug anyway?
Not. The bug won't fix ever.

> Does that mean the KDE project would like us to file another?
No, attach to the proper bug.
This one "focus under mouse - focus stealing preventinon doesn't work" is a logic conflict. If the focus is controlled by the mouse, it's not controlled by something else. This is not a WONTFIX but a CANNOTFIX.

> One that describes these remaining relatively minor anomalies?
It's not "minor anomalies". See links.

(In reply to comment #50)

> This one "focus under mouse - focus stealing preventinon doesn't work" is a logic conflict. If the focus is controlled by the mouse, it's not controlled by something else. This is not a WONTFIX but a CANNOTFIX.

It's not a logic conflict... because focus stealing prevention does more  than just prevent  focus stealing: it also prevents desktop yanking. On low focus stealing prevention, some applications such as thunderbird often switch desktops under the user, even with focus under mouse.

(In reply to comment #51)

> It's not a logic conflict... because focus stealing prevention does more 
> than just prevent  focus stealing: it also prevents desktop yanking. On low
> focus stealing prevention, some applications such as thunderbird often
> switch desktops under the user, even with focus under mouse.

"Unlikely"
The Exreme setting (and only that) would prevent an _active_ thunderbird window on one virtual desktop to pass the focus to another thunderbird window on another virtual desktop.
Ie. if you tried to open a message window by doubleclicking the message and the message is on another virtual desktop, thunderbird would send you there except you rule that away as "extreme".
That's it.

What you much more likely encounter (because there's somewhere a bug we tagged invalid) is that thunderbird (or firefox or songbird), which is a veeeeeery important application, switches the current desktop in order to be able (or not) to gain the focus for sure (because the usual behavior of WMs is to deny focus passing to other dektops) - or abuse the "tool" hint (meant for pagers and taskbars) to activate the window forcefully.

Neither could be blocked in the WM and is just a mozilla annoyance.

If you can explain how to trigger this in (preferably) firefox or thunderbird, i'll check what it does in particular but if it's just "opening thunderbird on a different virtual desktop changes that desktop" that's client cheating for sure and not be prevented by any focus stealing prevention.

(In reply to comment #52)

It's a while ago since I had observed these issues, so maybe things have changed/improved since then.

In Thunderbird, it used to switch desktops whenever a networking error happened which brought up an error dialog box. Nowadays, Thunderbird uses a different GUI element (flashbox?) to notify of such asynchronous errors.

In Firefox, it used happen if a site opened an alert() box. This is no longer an issue either, because Firefox now shows javascript alerts within its main window, rather than opening a dialog box.

A Lotus Notes client running within wine would also on occasion switch desktops.

All 3 could be cured with Focus Stealing Prevention (I had it on "High" for mozilla windows, and "Normal" for all others)


I've now set back my focus stealing prevention to None, and will see whether there are still any other misbehaving apps, and will report them here as soon as I see some.

Not required
Happens when a window on a different virtual desktop opens a modal dialog. (Your description sounded like that and "qdbus org.kate-editor.kwrite-24635 /kwrite/MainWindow_1/actions/file_open trigger" easily proved it)

No idea why that happens, but it's not correct.
The focus is where the mouse is and the mouse is not on the other desktop but in yakuake.
The mouse is not even on the kwrite window/dialog afterwards.

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

``Summary:do not allow desktop changes for mapping windows
   and unreasonable focus policies''

``if (!isOnCurrentDesktop() && options->focusPolicyIsReasonable()) {''

This patch seems a bit judgmental on people's preferences.
Any policy that disallows an application from switching desktops
from underneath you is, perforce, "unreasonable".  It explains
why it is so, so difficult to get this bug fixed.

(In reply to comment #56)

> This patch seems a bit judgmental on people's preferences.
> Any policy that disallows an application from switching desktops
> from underneath you is, perforce, "unreasonable".  It explains
> why it is so, so difficult to get this bug fixed.

First off:
this is no way what patch does or says - there's also the "allow" check (which is determined by FSP which are bypassed by the "unreasonable" policies) and this is all *in detail* explained in the review request.

Second:
this is not related to *this* bug at all, but cooked up by a comment from Alan, who has been - different from other people - very productive and professional on the topic and provided valuable input.

Third:
If you wish to complain about F(S)UM being tagged as "unreasonable" in the code, please build a time machine and complain to the developer who added/named it so like 8 years ago.

There will be no bullshit discussion about whether that's an acceptable function name (read the commit history to figure why the developer than picked that name, i don't care about such the least) and there will be no rename in the KDE4 cycle only to trigger merge conflicts with KDE5 branches.

(In reply to comment #57)
>  and there will be no
> rename in the KDE4 cycle only to trigger merge conflicts with KDE5 branches.
and also not in the KDE5 branch. I personally like the name. As a developer one also needs sometimes a little bit of fun and reading code with method names like that just make me smile :-) After all it's just a method name.

Git commit 07f89501ef738686d1e40297209aa971c667376c by Thomas Lübking.
Committed on 07/09/2013 at 21:35.
Pushed by luebking into branch 'KDE/4.11'.

no VD change for activation & unreasonable policy

F(S)UM mean "the focus is where the mouse is"
the mouse is not on the other virtual desktop
(and it was even granted regardless of the actual geometry/position)

The "unreasonable" focus policies expose an issue about
the present linked handling of "allow activation" and
"allow raising" (see https://git.reviewboard.kde.org/r/110919/ )

Activation would match "extreme" (if the window maps on the same
virtual desktop, half a mile away from the mouse, it won't
receive the focus) but not regarding raising (which is actually
an issue entirely different from FSP)

REVIEW: 112585

M  +1    -1    kwin/manage.cpp

http://commits.kde.org/kde-workspace/07f89501ef738686d1e40297209aa971c667376c