Possibly-relevant kwin settings: * Focus Follows Mouse - Mouse Precedence * 0ms delay * No focus stealing prevention * Raise on hover delayed 500ms * Active screen follows mouse In some cases, the window under the pointer doesn't get focus; this seems to be the result of quickly switching between a few windows. I'll attach a screenshot of the window layout I'm using to reproduce the behavior described. Reproducible: Sometimes Steps to Reproduce: 1. Place the pointer in the small terminal window on the right 2. Quickly (as fast as you can, basically) move the pointer horizontally from the small window across the large browser window into the mid-sized terminal window above it Actual Results: Perhaps 20% of the time the large window gains and retains focus, even when the mouse moves into the mid-sized window. Expected Results: The mid-size window always has the focus once the pointer is inside of it. I don't recall this behavior in version 5.5; I've only seen it in 5.6.
Created attachment 98451 [details] Window layout which can trigger the behavior
"Doesn't get focus" or "doesn't turn active" ? (does the titlebar look reflect the focus condition) And is firefox (? The browser, is it not?) a relevant part or does this also work with eg. kwrite?
It's neither active nor has focus: the titlebar is active for Firefox (which is still below the terminal), and keyboard input goes to Firefox. Excellent point on Firefox: I think I just assumed it was a kwin issue separate from the underlying programs, but it does appear to be related to Firefox/Mozilla. I tested a variety of different programs with various toolkits (Qt5, Qt4, Qt3, Motif, gtk2) and was only able to reproduce it with Firefox and Thunderbird (but not Seamonkey). Apologies for not being thorough enough in initial testing; I should have caught that.
no problem, can you please dump xprop and xwininfo -all on the firefox window?
Created attachment 98454 [details] xprop and xwininfo output These are not from the layout in the prior attachment (I'd closed all those windows), but I did verify that the loss of focus was happening with the Firefox instance I used to get the output here.
i can reproduce this with gvim and konsole my kwin settings are similar to the original reporter, except: - i don't have Raise on hover - i can reproduce this with Focus prevention Low (and possibly other values) - and both with "FFM Mouse precedence" and "FFM" without mouse precedence. steps to reproduce: 1. tile Konsole to left half of screen 2. run gvim command (this will cover the konsole window) 3. tile gvim to right half of screen using a keyboard shortcut (gvim window retains focus, even though i moved it away from under the mouse) 4. move mouse rapidly from one half of screen to the other results: - relatively often, when moving from gvim to konsole, gvim retains focus - very rarely, when moving from konsole to gvim, konsole retains focus (Possibly, I have managed to reverse the focus behavior at one point, i.e., when leaving unfocused gvim for focused konsole, gvim got the focus and konsole (now under mouse) lost it. But this might have been my mistake, i'm not able to reproduce it anymore.)
Created attachment 98461 [details] xprop and xwininfo for konsole and gvim
can you run xev to monitor the events?
I had assumed this could be caused by a WM_TAKE_FOCUS driven client (because of the "not with 5.5" claim), but that doesn't seem to be the case. Either we completely miss the crossing event on the second konsole or we run into some funny race - FF would see FocusIn after Konsole and was not removed from should_get_focus when konsole got the focus. Latter seems weird, so what might happen is that FF/GVim performs a "brief" sync mouse grab on enter or focus events? (If it was gtk3, I'd blame the touch/whell mess, but that looks like gtk2) Is it important that the window you come from is another konsole instance/window? Can you trigger this "kwrite -> firefox/gvim -> konsole"? What about: "konsole -> firefox/gvim -> kwrite" and: "kwrite -> firefox/gvim -> kwrite"
pretty sure my gvim is gtk3 (also gvim does in fact do funky stuff with mouse pointer, i've seen at least two bugs related to that over the years, so that could be it) i'll try to reproduce it with kwrite instead of konsole ... i'm not sure if i can manage it over three different windows, but i'll try :) also not sure about xev, how would i capture events for two windows at once? and if i ran two xevs simultaneously, it would be hard to correlate the events, no?
Created attachment 98476 [details] xev record for firefox and thunderbird Managed to reproduce between firefox and thunderbird (both gtk2) and catch it in a xev record. Not sure if that is of any help. At start, i'm trying to rapidly switch between the two, and at the end, I managed to get the pointer over firefox, while focus is retained on thunderbird. I mashed some keys as well. You can see that the window with mouse pointer (firefox) gets motion events, but not keyboard events. The focused window (thunderbird) does not get keyboard events, but instead gets PropertyNotify. at least it shows that konsole is not the important part.
At the moment i can very reliably reproduce between firefox and thunderbird, and much less reliably between firefox and something else. Between firefox and thunderbird, it is possible to get into a state where with relatively calm mouse pointer movement between the windows, the focus "sticks" on one of them for several transitions in a row. But I verified that it can happen with kwrite as well. I didn't manage to reproduce between two non-gtk apps.
further hint: for instance, when i'm switching between konsole -> gvim -> konsole Often the focus will move back to konsole properly, but the gvim window will be highlighted in taskbar -- the same way new windows are, or windows that try to notify you of something. This is not limited to gvim, firefox and thunderbird do it too.
It means gvim tried to obtain the focus, but this was denied by the focus stealing prevention (though you claim it's deactivated) FSP would not intercept if the focus is "nowhere" (or on the desktop) The xev logs show some direct focusout/focusin sequences, ie. the focus was not passed there for an enter/motion event. If you create special "kcmshell5 kwinrules" for FF/TB/GVim and set the focus stealing prevention to "extreme", can you still reproduce this?
(In reply to Thomas Lübking from comment #14) > It means gvim tried to obtain the focus, but this was denied by the focus > stealing prevention (though you claim it's deactivated) I was able to reproduce the original bug (wrong focus switching) with FSP off. I can't reproduce the "highlight on taskbar" with FSP off. (i have multiple computers with KDE, with slightly different settings, that's why i got this FSP thing now) I do sometimes see the focus "flicker", the gtk window is defocused for a moment and then gets its focus back. Which would confirm what you said: the gtk windows try to regain focus after losing it. (and sometimes they succeed, other times FSP stops them) > If you create special "kcmshell5 kwinrules" for FF/TB/GVim and set the focus > stealing prevention to "extreme", can you still reproduce this? I switched the whole system to "extreme" and can no longer reproduce the problem. (i do see the taskbar highlights). Unfortunately, this is not a good workaround for me because it means that new gvim windows launched from terminal don't go to foreground. So what now? It seems clear that gtk windows try to take back focus when they lose it. But other window managers don't seem to trigger this behavior.
What means "other WMs" - mutter? Can you please attach ~/.config/kwinrc with desired (and troublesome) settings?
Created attachment 99034 [details] kwinrc of config
I tried xfwm4 as a window manager inside KDE and could not reproduce the issue. I didn't manage to run mutter this way, but i don't see this issue on my GNOME3 desktop.
> FocusStealingPreventionLevel=2 The focus moves despite the medium FSP? Or does this cause a flashing taks item? > DelayFocusInterval=0 Wild guess, what if you raise this to, say, 100ms?
(In reply to Thomas Lübking from comment #19) > > FocusStealingPreventionLevel=2 > The focus moves despite the medium FSP? Or does this cause a flashing taks > item? both, it doesn't seem to be deterministic setting to High or Extreme prevents the focus loss and only causes flashing taskbar. on Low and Medium, either can happen. > > DelayFocusInterval=0 > Wild guess, what if you raise this to, say, 100ms? yes, this seems to help, i'm not able to reproduce the problem anymore. (not deliberately anyway. i'll see if it crops up again while i'm working, but it seems to be a workable solution) for the record, xfwm4 has the focus delay feature too, and even on the lowest setting the problem doesn't appear. but i don't know whether it's actually zero or some small nonzero number
Created attachment 99071 [details] Ogg video showing problem I see this with KDE 5.6.3 on Fedora 23. I didn't see this with the previous (5.5.5) version. In the video, the focus stays with the firefox window if the mouse pointer only traverses it for a short enough time. I move the mouse from top to bottom xterm too slowly, but from bottom to top fast enough to show that the focus stays with firefox. Then, cursor keys move the firefox pane, and ^T opens a new tab. A mouse click then restores the correct focus location. Note, that this is with focus delay of 0. Increasing the focus delay to 25ms or above works around this - I guess that this is longer than the time that the pointer stays in the firefox window.
That's even on FSUM. Can you reproduce this when deactivating the titlebar for the lower window? (Alt+F3 shows a menu for the focused window where you can set this)
With the titlebar hidden (Alt+F3 -> More Actions -> No Border), I can still reproduce this problem.
A possibly related bug is that the focus can change even without the cursor moving. I've noticed this only in one specific case. Run firefox with the bluejeans (video conference) plugin. Move the pointer to another window (xterm in my case). Wait. The focus will change to the firefox/bluejeans window even though the pointer has not moved.
The client will just focus itself. Does that also happen w/ extreme focus stealing prevention?
I have Window Management -> Window Behaviour set all the way to the right (Hover) - "Focus Strictly Under Mouse". With this setting, Focus stealing prevention is greyed out. The default was Low. - changing it to Extreme (still greyed out) makes no difference.
(In reply to Julian Coleman from comment #26) > The default was Low. - changing it to Extreme (still greyed out) makes no difference. Sounds like bug #360878 - FSP doesn't work w/ F(S)UM, but it's supposed to be not configurable and always apply. Do you have troubles w/ other models as well (try "Focus Follows mouse")?
With Focus Follows Mouse (and FFM - Mouse Precedence) plus Fsp = Extreme, the focus is always under the mouse (i.e. I cannot reproduce this bug).
Update: the bug is still there with FFM - it's just less frequent, and I can't reproduce it on demand.
I've been seeing this bug quite regularly since moving from 4.14 to 5.6.5. With my usual settings (Focus Strictly Under Mouse and 0 ms delay) it's extremely easy to reproduce. Put 2 xterm windows near each other with a small gap, then put a Firefox window in the background in that gap. Move your mouse back and forth between the 2 xterm windows quickly and eventually (5-10% of the time?) you'll find that the focus isn't under your mouse, even though you're using "Focus Strictly Under Mouse"...the focus will be on the small sliver of the Firefox window inbetween the two xterm windows. If I switch to "Focus Follows Mouse - Mouse Precedence" mode, and no Focus stealing prevention, it's still easily reproduceable. With this new mode, though, I have the option of turning on Focus stealing prevention, and when I set that to "Low" it becomes extremely hard to reproduce (and occasionally the Firefox entry in the taskbar gets highlighted red - I guess this means a focus "steal" was prevented?) Going back to my preferred mode, "Focus Strictly Under Mouse", and then setting a delay of 20 ms also made it very hard to reproduce (or maybe impossible, haven't seen it yet...) So, maybe the short delay is the way to go, unless/until this is fixed. By the way, I wasn't able to reproduce this with 3 xterms, had to have a Firefox window involved.
If I get rid of the xterm windows, and use 2 Firefox windows and 1 Thunderbird window (Firefox -> Firefox -> Thunderbird, with the middle Firefox being a small sliver in the background), then it becomes extremely easy to reproduce. The problem happens 50%+ of the time, kind of crazy in fact. (This is with FSUM and 0 ms delay) 10 ms makes it a lot less common, 20 ms makes it pretty rare but still seen it happen. Haven't been able to reproduce with 25+ ms yet.
Update: even with 25 ms delay, this problem still happens occasionally. I'm guessing it all depends on how fast you're moving the mouse cursor and how long it takes the traverse the other windows you're moving past, on your way to your final destination. This has made KDE frustrating to use. Is there any hope for a fix in the near future? My comment #31 makes it extremely easy to reproduce on demand.
Tried working around this by switching to "Focus Follows Mouse - Mouse Precedence" and setting some "Focus stealing prevention", but even that doesn't work. At a prevention level of "Medium" and delay of 25 ms, problem still happens regularly enough. Focus stealing prevention modes above "Medium" are unusable, because they break apps (I can't even use the KDE Launcher at "High" or "Extreme"). It seems the only way to make focus-follows-mouse work properly in KDE currently is by setting a ridiculously long delay.
I have been plagued by this bug for several months now, and i am glad to see that it has been reported in detail by others here. However, i am utterly disappointed that such a serious and debilitating bug ("This has made KDE frustrating to use", said Bob Farmer) has been around for 11 months since first reported, and there has been no further comment (or, better yet, action) from KDE developpers for about 8.5 months now (!!!) I visited the KDE stand at a recent FOSS event and i was told that there is exactly ONE (1) (!!!) person involved in kwin development! I hope this is wrong... but i cannot help wondering whether this might explain these delays... I would like to hope that making fancy YouTube promotional material has not become more important to the KDE Project than technical merits...
Yes, it's pretty crazy if this bug is still around (I admittedly haven't tested the most recent releases). It made KDE unusable for me. After ~19 years of using KDE, I was forced to switch to Xfce because of this bug.
Well, i also switched for a while to LXQt due to *another* major bug for me, i.e. that the konsole kept crashing (Bug 364616). Someone changed the status of that bug to "RESOLVED UPSTREAM" though it's certainly not been fixed. However, it happens less often now, and i have found ways to save my work when it happens, so i tentatively and hesitantly switched back to KDE. But bugs like this one with mouse focus, and a few other less minor ones, and most of all the Qt/KDE developers' attitude, move me ever closer to switching once and for all. I had written some more, not at all flattering stuff, in my previous comment, but i forced myself to delete it because this is a "bug report" area. But i have seen comments from plenty of other KDE users who are infuriated with the senseless "upgrading" to immature, alpha-testing-level products that the Qt & KDE projects have been forcing on their users the last few years. It's a pity to see such a nice project being destroyed from the inside...
I revisit this bug from time to time, especially at moments when i feel like i need to be amazed by something... It is amazing, indeed, that nobody bothers to fix this serious bug that cripples desktop functionality under common usage scenarios. My only explanation, if i want to avoid evoking insanity, is that most KDE developers do not use the "focus follows mouse" mode, probably because nobody in their age group has experienced the old X desktops and the advantages of FFM. So if they don't use it, why bother fixing it, right?... However, they could at least be *honest* and remove the FFM option from KDE altogether rather than pretending it works and advertising it as a supposed sign of KDE's extensive configurability...
I can tell you one thing: if you write comments like that you can be sure the bug won't get fixed. Such comments are demotivating and there are more bug reports with friendly and constructive users than we can fix anyway.
Martin, it's been 3 years, almost down to the day, since this bug was opened. How many of the people seriously impacted by it do you think are still waiting for a fix and have not already moved to greener pastures? My posting was not meant to incite developers to action; at this point, it was more of an expression of amazed disappointment. But hey, maybe we are just the proverbial 10% or less of the user base whining childishly about "our" own obscure little bug while developers have more interesting stuff to work on --even though "focus follows mouse" represents 4 out of the 6 focus options available, and firefox is probably open most of the time on most people's workspace. In any case, i think it is not very tasteful to say that my comments may be the reason the bug may not get fixed. It's not just "my" bug after all, why penalize others for my bad behavior? Please, go ahead and fix it, preferably before Qt 6 is out, and i can promise that i will never use the bug fix myself if that makes you guys feel more motivated in the knowledge that people like me won't benefit from your work.
This bug was reported against an outdated version of KWin. We have made many changes since the. If the issue persists in newer versions can you reopen the bug report updating the version number.