| Summary: | Impossible to click on the taskbar to bring up Dota 2 after a recent update | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Martin Roth <captain_rage> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dave.knippers, shawn.peterson |
| Priority: | NOR | Keywords: | regression |
| Version First Reported In: | 5.19.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/2717252861048794737f6aa72c90548404814746 | Version Fixed/Implemented In: | 5.19.4 |
| Sentry Crash Report: | |||
|
Description
Martin Roth
2020-07-15 01:48:00 UTC
I have experienced the same thing. I believe the change was after a recent system update, not a dota update. I have found two additional methods to bring the game back up: (1) right click the menu item and unselect "minimize" (2) use the scroll wheel on the task bar. i think you need "cycle through tasks" selected in the task bar's behaviour settings. versions without issue: KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.70.0 Linux: 5.6.7-gentoo Qt Version: 5.15.0 versions with issue: KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Linux: 5.7.9-gentoo Qt Version: 5.15.0 one additional comment: it seems to effect only dota 2. i haven't been able to see the behaviour in other fullscreen applications. I can confirm that this has nothing to do with dota 2. It appears to be any fullscreen application (although the only ones that I have that I can test are games. I have tested it with dota 2, dota underlords, as well as 0ad (not a steam game). I tried a different kernel, and I tried switching between different compositing layer thingies (open gl 2.1, 3, xrender). None of this makes any difference. i must not have tested enough to say for sure it's only in dota, but it was the only one i managed to get it to fail on. (In reply to dave knippers from comment #4) > i must not have tested enough to say for sure it's only in dota, but it was > the only one i managed to get it to fail on. What application did the bug not show up for? Just curious what the difference is. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/126 Git commit 2717252861048794737f6aa72c90548404814746 by Vlad Zahorodnii. Committed on 21/07/2020 at 09:56. Pushed by vladz into branch 'master'. Partially revert a0c4a8e766a2160 Unfortunately, a0c4a8e766a2160213838daf6f71c7ae6c3705df has a major bug where clients that track focus events may get confused by focusToNull(). One such a notable example is Dota 2. It tracks the focus events to minimize itself after the keyboard focus has been lost as well stop playing music while it's in background. So, when we call focusToNull(), Dota 2 will receive a corresponding FocusOut event and ask the window manager to minimize it. It doesn't really matter that the FocusOut event is going to be followed by a FocusIn event because when a window is minimized, kwin will activate the next one in the focus chain. Since those issues can't be fixed from the window manager's side, this patch partially reverts a0c4a leaving only the autotest. FIXED-IN: 5.19.4 M +2 -0 autotests/integration/x11_client_test.cpp M +0 -5 x11client.cpp https://invent.kde.org/plasma/kwin/commit/2717252861048794737f6aa72c90548404814746 Git commit 892d2ad128e53e5ad4d3ec70c87a4f802f10e023 by Vlad Zahorodnii. Committed on 22/07/2020 at 12:36. Pushed by vladz into branch 'Plasma/5.19'. Check if we successfully restored input focus In rare cases, Workspace::restoreFocus() may fail, for example when the most recently activated client is about to be destroyed or unmapped. If it happens that we cannot restore the focus, then mark the window in FocusIn event as active. (cherry picked from commit 555885072d8ff126168994d6d9c3b9692b1b1b00) M +1 -1 abstract_client.h M +20 -11 activation.cpp M +0 -2 autotests/integration/x11_client_test.cpp M +8 -4 events.cpp M +2 -1 internal_client.cpp M +1 -1 internal_client.h M +3 -3 workspace.h M +15 -5 x11client.cpp M +1 -1 x11client.h M +3 -1 xdgshellclient.cpp M +1 -1 xdgshellclient.h https://invent.kde.org/plasma/kwin/commit/892d2ad128e53e5ad4d3ec70c87a4f802f10e023 Git commit 8894338eda9da05b687fdde3190ceeaef2ee9090 by Vlad Zahorodnii. Committed on 22/07/2020 at 13:03. Pushed by vladz into branch 'Plasma/5.18'. Check if we successfully restored input focus In rare cases, Workspace::restoreFocus() may fail, for example when the most recently activated client is about to be destroyed or unmapped. If it happens that we cannot restore the focus, then mark the window in FocusIn event as active. (cherry picked from commit 555885072d8ff126168994d6d9c3b9692b1b1b00) (cherry picked from commit 892d2ad128e53e5ad4d3ec70c87a4f802f10e023) M +1 -1 abstract_client.h M +20 -11 activation.cpp M +0 -2 autotests/integration/x11_client_test.cpp M +8 -4 events.cpp M +2 -1 internal_client.cpp M +1 -1 internal_client.h M +3 -3 workspace.h M +15 -5 x11client.cpp M +1 -1 x11client.h M +3 -1 xdgshellclient.cpp M +1 -1 xdgshellclient.h https://invent.kde.org/plasma/kwin/commit/8894338eda9da05b687fdde3190ceeaef2ee9090 |