Bug 457457 - Strange window activation behavior
Summary: Strange window activation behavior
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.3
Platform: Other Other
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2022-08-03 18:06 UTC by Alex
Modified: 2024-03-08 20:45 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2022-08-03 18:06:04 UTC
Since the upgrade to 5.25.3, I got a strange problem with activation on mouse contact (mouse preferred) and Focus steal prevention, I think.

Sometimes when I click, for example, a link in an application, it opens in Firefox and Firefox does not take the focus but comes to front. When I then move the cursor to the title bar, the previous window comes to front (but doesn't have focus).

Other observed variants include that I have, for example, a non-maximized terminal window in front of a maximized window. When I move the cursor from the panel to the maximized window, suddenly the maximized window comes to front.
The strange thing then is, when I click the terminal window item in the (icons-only-)taskbar, it minimizes the terminal (seems correct), but clicking it again brings it to front and instantly covers it with the maximized window again.

Doing this again and again, after some tries the terminal stays in front and sometimes I can even move the cursor over the maximized window to the free-floating terminal window.

Sometimes I also get the behavior when using click-to-focus and trying to bring the previously hidden floating terminal window to front. Both when it is hidden and when it is minimized, it shortly appears on front and then is covered even when the mouse is still on the taskbar item.

I would have suspected that the maximized window is somehow aggressive about being in front, but the only thing I changed is the KDE upgrade (together with some other X11 upgrades in Debian) but not the programs with the weird behavor.

Sorry when the post looks a bit incoherent, but I am also struggling to find out which conditions cause this behavor.

SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Graphics Platform: X11
Comment 1 Alex 2022-08-03 18:08:44 UTC
The window being maximized doesn't seem neccessary either. I tried a window that is resized to full size and not maximized and get the same behavor.

Focus follow mouse seems to be related in the case when I can move the cursor over the background window to the floating window and the floating window gets hidden in the moment the cursor touches it.

So it seems to be related to window focus, both from focus-follow-mouse and from simple activation via the taskbar.
Comment 2 Alex 2022-08-04 06:50:33 UTC
floating windows (together with activation by mouse contact) only make it easier to trigger the bug, but I just had similar behavor with two maximized windows.
Comment 3 Dylan Piergies 2024-03-08 20:45:15 UTC
I'm seeing a problem that's likely related (or the same issue).

Sometimes mouse events seem to be reaching the window behind the window I'm pointing at.

I don't see windows being raised as the reporter described but I have: `clickRaise: false` and `commandWindow1: MouseActivateAndPassClick` which may explain that. If I set `clickRaise: fatruelse` and/or `commandWindow1: MouseActivateRaiseAndPassClick` these options (which is the default) I would expect to see exactly the reported behaviour.