Using focus under mouse or focus strictly under mouse (what can I say, I cut my teeth on that), it's possible for focus to be stolen by a window on another virtual desktop that grabs the focus. It should be possible to block that behavior (or alternatively never allow a window on another virtual desktop to grab focus). Reproducible: Always Steps to Reproduce: 1. Start a long-running operation using LibreOffice (4.2.7, in my case) on virtual desktop 2. 2. Switch to virtual desktop 1 3. Actual Results: When the long-running operation in LibreOffice on virtual desktop 2 finishes, the focus is grabbed away from virtual desktop 1, and any keys typed will go to LibreOffice on virtual desktop 2. Expected Results: Focus should remain in virtual desktop 1. (This may have broken around 5.5.4 or 5.5.5; I think it worked correctly before)
... or rather unconditionally on FSUM and if (active_client) on FUM. There's a chance that your case is covered by https://git.reviewboard.kde.org/r/127153/ (5.6.0, not sure whether it made it into the beta) It's unlikely (while possible) that this changed with a kwin release, maybe LO switched to some KF5/Qt5 integration (does it show a dialog when the job is done?)
No dialog. The LibreOffice window on the other virtual desktop simply gets the focus and whatever window the mouse is under loses it. This is LibreOffice 4.2.7, which is obsolete (I'm using it because I have this horrendously complex spreadsheet that doesn't work properly on any newer version due to bugs in LibreOffice, which are out of scope here). So nothing has changed there. Again, there have been upgrades to both KDE Framework and QT5 that I installed recently that may have coincided with this problem starting.
Also, the virtual desktop doesn't switch (which would be a problem in its own right).
More information: I can reproduce this with focus follows mouse/mouse precedence, with focus stealing prevention anything up to high. It does not happen with extreme focus stealing prevention. It is not specific to focus under mouse. The particular operation I'm doing in LibreOffice is Insert->Names->Manage... . After I edit one of the names and click OK in the Manage Names dialog, the dialog does not immediately pop down. Instead, LibreOffice runs continuously and hard for several minutes, after which the dialog goes away (that's not a bug in LibreOffice per se; the spreadsheet is just ridiculously big and complex). That is the exact moment at which the window in the other virtual desktop loses focus (as determined by watching the pager in the panel) and it switches to the main LibreOffice window. After that, LibreOffice continues to run for another minute or so before accepting input. By typing on the keyboard and then switching back to the other virtual desktop, I can verify that the keyboard focus has been given to LibreOffice. (Just a gripe, I hate this term "unreasonable focus policies". It's not apparent what's unreasonable about wanting the focus to always remain under the mouse. I know alt-tab and such won't work, but I don't use them and never have. If I have a dozen or more windows up, alt-tab is useless to me because it goes through them in no particular order. I use keyboard accelerators to raise/lower windows, and I can also select them from the panel. I cut my teeth on X9/X10 in the mid 1980's and really like that simple paradigm.)
What kind of window is active on the desktop you'd like to stay on. LibreOffice one as well? (Fyi, It's "::focusPolicyIsReasonable()" since KDE2 and we're not gonna draw a git wall because users don't like how it's called :-P)
Firefox, xterm, and pidgin, not LibreOffice. All of my LibreOffice windows (there were two documents in addition to the popup) are on the other virtual desktop. (To be precise, the FF, xterm, and pidgin are on VD#0, LO on VD#2, and 6 total.)
Ok, please ensure to test this on 5.6.0 - there's a good chance it's covered by forementioned patch, but actually™ the virtual desktop should change alongside the focus and it may be that LO underruns checks to "return" the focus. I though might have an idea what changed to cause this. Can you please take an "xprop" (run it in konsole, click the window and attach the output) of the main LO window that gets the focus (no matter when. ie. it's not required to have it steal the focus etc.)
Ugh. Virtual desktop switching is really bad news. I just don't want the focus to switch, period. I'll be installing 5.6.0 shortly. If it does actually switch the desktop -- even with mouse follows/under focus -- I'll be filing a bug against *that*. Here is the xprop output (5.9.5): _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 17, 0 _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 17, 0 _NET_WM_DESKTOP(CARDINAL) = 2 _KDE_NET_WM_ACTIVITIES(STRING) = "a69c2087-1863-4647-8743-f5bcff184776" WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x98015e2 bitmap id # of mask for icon: 0x98015e3 window id # of group leader: 0x9800001 XdndAware(ATOM) = BITMAP _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 1385010480 _NET_WM_ICON(CARDINAL) = Icon (26 x 26): ░▒▒▒▒▒▒▒▒▒░ ░▒▒▒░ ▒ ░░ ░▒▒▒▒ ▒ ▒░ ░▒▒▒ ▒ ▒░ ░▒▒ ▒ ▒░ ░░ ▒ ▒░ ▒ ▒░ ▒ ▒░ ▒ ░░░░░░░░░░░░ ▒ ▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒▒▒▒▒▒▒▒▒▒▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▓▒▒▒▒▒▒▒▒▒▒▓ ▒ ▒ ▓ ▒ ▒ ▓ ▒ ▒░ ▓▓▒▒▒▒▒▒▒▒▓▓ ░▒ ▒░ ░▒ ▒░ ░▒ ▒░ ░▒ ▒░░░░░░░░░░░░░░░░▒ ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ Icon (16 x 16): ░▒▒▒▒▒▒░ ░▒▒▒ ▒ ░▒ ▒▒▒ ▒ ░▒ ▒▒ ▒ ░▒ ▒ ▒ ░▒ ▒ ░▒ ▒ ▒▒▒▒▒▒▒ ░▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒▒▒▒▒▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒▒▒▒▒▒▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒░ ▒▒▒▒▒▒▒ ░▒ ▒░ ░▒ ▒░░░░░░░░░░░░▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒ _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 159389149 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME(CARDINAL) = 1477809551 _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x98015dc WM_CLIENT_LEADER(WINDOW): window id # 0x9800001 _NET_WM_PID(CARDINAL) = 12263 WM_LOCALE_NAME(STRING) = "en_US.UTF-8" WM_CLIENT_MACHINE(STRING) = "rlk-mobile.rlk" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 0 by 0 window gravity: Static WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "libreoffice", "libreoffice-calc" WM_ICON_NAME(STRING) = "rowing.ods - LibreOffice Calc" _NET_WM_ICON_NAME(UTF8_STRING) = "rowing.ods - LibreOffice Calc" WM_NAME(STRING) = "rowing.ods - LibreOffice Calc" _NET_WM_NAME(UTF8_STRING) = "rowing.ods - LibreOffice Calc"
The point is that if it was actually kwin that activates the other window (and it should so even if that manages to just fetch the focus itself) a desktop switch alongside that would to be expected. And no: windows on other desktops are not supposed to get the focus (except when passed there client internally, ie. if window "a" on desktop "1" and window "b" on desktop "2" belong to the same application and window "a" has the focus, it might pass it on to window "b", assuming that the client knows best which of its own windows should have the focus, eg. because of some user interaction) This is completely regardless of the focus distribution approach.
Still happens in 5.6.0.
Another, simple case: 0) Focus follows mouse, mouse precedence, focus stealing prevention medium, both autoraise and click to raise turned off. 1) Start konsole, put it on the right hand side of the screen, leave mouse over the konsole window. 2) In the konsole, run konsole Result: second konsole window gets focus. Expected result: focus stays with the original konsole window With focus stealing prevention high this doesn't happen, but then it's very difficult to use the KDE menu from the panel (I have to explicitly defocus the mouse by clicking over the root window in order to be able to use it). So this would appear not to be related to focus under mouse.
ffm is like Ctf, mInus the need to click. the focus is not bound to the mouse position, but the fsp policy. the precedence is relevant to the focus decision when a window is closed and the wm needs to select then next one. this is *not* a bug. the plasma popup situation is ridiculous, but unrelated. the popup is simply buggy (due to caveats of qml)
No, because I haven't closed the first konsole window. When I type "konsole", the *new* konsole window that pops up gets the focus away from the existing one. The same thing happens with xterm or gnome-terminal: when I create a new window, it gets the focus. I tried another experiment: in an xterm, I ran % sleep 5; konsole and moved the mouse (and focus) to another window (tried with both firefox and pidgin). After 5 seconds, when the konsole popped up, the focus was switched to it despite medium focus stealing prevention.
(In reply to rlk from comment #13) > When I type "konsole", the *new* konsole window that pops up gets the focus away from > the existing one. Yes, this is determined by the focus stealing prevention (as you figured) > After 5 seconds, when the konsole popped up, the focus was > switched to it despite medium focus stealing prevention. Yes, because the medium FSP won't deny it under this circumstances (high will if uncertain about the start time) The new windows "start time" is newer than the last focus assignment or "interaction" (usertime stamp) The extreme FSP will keep the focus where it is, the high one if uncertain about one of the timestamps and actuallly™ two konsole windows might end up in the same group (depends on some attributes, didn't actually check) what might allow them to distribute the focus "among" each other as it pleases them (but I don't think so, there should be a correct PID split atm) FSP isn't trivially doing "the right thing" and there's bug #110543 and ultimately https://git.reviewboard.kde.org/r/124130/ (which would preserve the focus on the if you're still typing in konsole at a reasonable speed) FFM unlike FUM/FSUM *is* subject to focus distribution (that's the major differentce between the first and second two policies); if you want to keep the focus where it is, you'll have to pick extreme FSP.
I see. The comment "raising is split from activation, we are more generous on former, so that the user does not easily miss windows that are denied activation" (from reviewboard 124130) describes what I have in mind. I want new top level windows (as opposed to things like dialogs, menus, and such) to not get focus unless I explicitly activate them by moving the mouse into them, but I do want them to be visible. But I don't think I want the timestamps to come into play. Even if I haven't typed into the current window in an hour, I don't want a window that newly pops up to get focus. There's the other problem of focus going to windows on a different virtual desktop. It's hard for me to see how that makes sense with any focus policy. I can well believe there are a lot of corner cases here.
So there is still a problem: when I'm saving a document in LibreOffice, it grabs focus away a couple of times when it's done even with focus stealing prevention set to extreme and when I was typing into Firefox in a different virtual desktop (which shouldn't matter -- my understanding is that with FSP=extreme an application should *never* be able to grab focus, period). FSP=high or extreme also renders the K menu completely useless; I had to run systemsettings5 manually to set the FSP back to medium to be able to get the K menu.