Bug 460072 - Window order won't allow input - after working for an hour or so (kwin_x11)
Summary: Window order won't allow input - after working for an hour or so (kwin_x11)
Status: REPORTED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-06 22:49 UTC by alex
Modified: 2023-02-28 02:27 UTC (History)
1 user (show)

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


Attachments
Window Stacking Error demonstration (2.30 MB, video/mp4)
2022-10-17 22:21 UTC, alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2022-10-06 22:49:01 UTC
SUMMARY
After running for some time (typically 30+minutes), kwin can end up in a state where windows that are visually on top will not accept focus.  They will not accept input, and actions like scroll wheel act on the window below them.
The application window is actually still fine, as 'kwin_x11 --replace' restores everything to normal.
Happens most often when working across multiple activities.

***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Sorry, unable to reproduce consistently with specific steps, but it does occur multiple times daily.  (to the extent I have bound a Keyboard shortcut to restart kwin_x11)
2. 
3. 

OBSERVED RESULT
Windows of a running application cannot be focussed or moved, despite being visually 'on top'.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6

ADDITIONAL INFORMATION
Comment 1 alex 2022-10-06 22:53:35 UTC
Just adding that I'm aware this is a terrible report I've made.
If there's any form of logging I could enable that could help me gather relevant details when it happens, please let me know.
Comment 2 Nate Graham 2022-10-10 03:05:09 UTC
Could you try again with Plasma 5.26, which is due to be released in two days? Thanks!
Comment 3 alex 2022-10-11 01:17:04 UTC
(In reply to Nate Graham from comment #2)
> Could you try again with Plasma 5.26, which is due to be released in two
> days? Thanks!

Thanks Nate!
OK, once 5.26 lands for openSUSE Tumbleweed (probably next week), I'll give it a spin and see.
Comment 4 alex 2022-10-17 22:21:40 UTC
Created attachment 152972 [details]
Window Stacking Error demonstration
Comment 5 alex 2022-10-17 22:42:12 UTC
Hi, as requested I'm checking back in with Plasma 5.26, and the problem remains.

I've managed to narrow down reproducing it a bit, and attached a video showing the problem I have.

So updating:
STEPS TO REPRODUCE
1. Open multiple windows on one Activity, and multiple windows on a second Activity
2.  Switch between windows of an activity using ALT-TAB or by left-clicking visible area of window
3.  Switch to the other activity, then switch between windows of this second  activity using ALT-TAB or by left-clicking visible area of window

OBSERVED RESULT
Window visibility and focus state can become broken as shown in attached video.
Main points of video, using 3 windows for demonstration:
0-2s:   Starting with Slack active and on top, I click on Konsole which activates and raises as expected.
3-6s:   Having clicked on Kate, it is active (see cursor and task manager), but remains visually under Konsole and Slack.
7-12s:  Trying to click on Slack which is on top, but all interaction is with the invisible parts of the Kate window.
13-25s:  I click on part of the Slack window which doesn't overlap Kate, and it activates Slack but brings Kate to the top!
26-end:  I use krunner to kwin_x11 --replace, and all order returns to normal.  Note also that Vokoscreen's ShowClick and Halo cursor indicators work after replacing kwin_x11, whereas before they may have been rendering under the windows?

EXPECTED RESULT
The active window on an activity should always be raised to top and be visible in front of others*
*Obviously except if window is Keep Above Others, or other settings say otherwise.  
My Window Behavior is set to:
Focus Follows Mouse, Medium FSP, "Click raises active window", but not "Raise on Hover".

Updated  System info
Operating System: openSUSE Tumbleweed 20221015
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Kernel Version: 6.0.1-1-default (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: Quadro P620/PCIe/SSE2
Comment 6 alex 2022-10-17 23:11:32 UTC
Sorry, adding after further testing:
ADDITIONAL INFORMATION
I've just tried Plasma Wayland for the first time in a while, and I could not reproduce the error there.  So while with my little knowledge it seems to involve kwin_x11, that may be a useful datapoint to confirm.
Plasma Wayland has improved a lot since I last tried - there was nothing blindingly broken.  Sadly the performance was very stuttery with very high CPU use (up to 95% of a core) by kwin_wayland, so I won't be up to switch any time soon.
Comment 7 alex 2023-02-28 02:27:00 UTC
Update:
As of Plasma 5.27.0, it looks like this may have been resolved.
(possibly related to heroic work being done in kwin generally?)

I had stopped using Activities altogether due to this: I now plan to resume using Activities (yay!), and will change status to resolved in a couple of days if all is well.