[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=361940

David Edmundson  changed:

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |UNMAINTAINED

--- Comment #40 from David Edmundson  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #39 from orionbe...@gmail.com ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #38 from Martin Flöser  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #37 from orionbe...@gmail.com ---
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...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #36 from orionbe...@gmail.com ---
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...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Bob Farmer]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #35 from Bob Farmer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=361940

orionbe...@gmail.com changed:

   What|Removed |Added

 CC||orionbe...@gmail.com

--- Comment #34 from orionbe...@gmail.com ---
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...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Martin Gräßlin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

Martin Gräßlin  changed:

   What|Removed |Added

  Component|general |core

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Bob Farmer via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #33 from Bob Farmer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Bob Farmer via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #32 from Bob Farmer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Bob Farmer via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #31 from Bob Farmer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Bob Farmer via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

Bob Farmer  changed:

   What|Removed |Added

 CC||k...@bfarmer.net

--- Comment #30 from Bob Farmer  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #29 from Julian Coleman  ---
Update: the bug is still there with FFM - it's just less frequent, and I can't
reproduce it on demand.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #28 from Julian Coleman  ---
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).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

Thomas Lübking  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=360878

--- Comment #27 from Thomas Lübking  ---
(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")?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #26 from Julian Coleman  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #25 from Thomas Lübking  ---
The client will just focus itself.
Does that also happen w/ extreme focus stealing prevention?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #24 from Julian Coleman  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #23 from Julian Coleman  ---
With the titlebar hidden (Alt+F3 -> More Actions -> No Border), I can still
reproduce this problem.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #22 from Thomas Lübking  ---
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)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Julian Coleman via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

Julian Coleman  changed:

   What|Removed |Added

 CC||jcole...@redhat.com

--- Comment #21 from Julian Coleman  ---
Created attachment 99071
  --> https://bugs.kde.org/attachment.cgi?id=99071=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Nick Cross via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

Nick Cross  changed:

   What|Removed |Added

 CC||k...@goots.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #20 from matejcik  ---
(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

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #19 from Thomas Lübking  ---
> 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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #18 from matejcik  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #17 from matejcik  ---
Created attachment 99034
  --> https://bugs.kde.org/attachment.cgi?id=99034=edit
kwinrc of config

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #16 from Thomas Lübking  ---
What means "other WMs" - mutter?
Can you please attach ~/.config/kwinrc with desired (and troublesome) settings?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #15 from matejcik  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #14 from Thomas Lübking  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #13 from matejcik  ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #11 from matejcik  ---
Created attachment 98476
  --> https://bugs.kde.org/attachment.cgi?id=98476=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #10 from matejcik  ---
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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #9 from Thomas Lübking  ---
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"

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Martin Gräßlin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #8 from Martin Gräßlin  ---
can you run xev to monitor the events?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[matejcik via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #7 from matejcik  ---
Created attachment 98461
  --> https://bugs.kde.org/attachment.cgi?id=98461=edit
xprop and xwininfo for konsole and gvim

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #5 from k...@happyjack.org ---
Created attachment 98454
  --> https://bugs.kde.org/attachment.cgi?id=98454=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #4 from Thomas Lübking  ---
no problem, can you please dump xprop and xwininfo -all on the firefox window?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #3 from k...@happyjack.org ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #2 from Thomas Lübking  ---
"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?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361940

--- Comment #1 from k...@happyjack.org ---
Created attachment 98451
  --> https://bugs.kde.org/attachment.cgi?id=98451=edit
Window layout which can trigger the behavior

-- 
You are receiving this mail because:
You are watching all bug changes.