Bug 424223 - Impossible to click on the taskbar to bring up Dota 2 after a recent update
Summary: Impossible to click on the taskbar to bring up Dota 2 after a recent update
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: 5.19.3
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-07-15 01:48 UTC by Martin Roth
Modified: 2020-07-22 13:07 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 5.19.4
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Roth 2020-07-15 01:48:00 UTC
SUMMARY
Presumably after a recent system upgrade on Arch Linux (running using predominantly standard and default settings of KDE and Plasma) it isn't possible to click on Dota 2 in the taskbar / panel to bring the game back up. The game launches as normal, however, and once started, the edge effect and tile windows effect don't work (maybe starting Dota 2 disables that part of the compositor). 
Disabling the compositor (using alt-shift-F12) prior to launching the game doesn't help; the bug persists. The only way to get back into the game is to alt-tab to the Dota 2 window, or hover the Dota 2 taskbar icon and click on the preview image (which always shows the icon of the game, and no live preview).
Also, when the finding and queuing a game, the game gets minimized (when a match is found a desktop notification was normally shown on the desktop, but when the game was active nothing special happened, but now when the game is active it gets minimized, which is not supposed to happen). 

STEPS TO REPRODUCE
1. Start Dota 2 (default settings, full screen)
2. Alt-tab or press the "show desktop" hotkey
3. Click on the Dota 2 icon on the taskbar / panel

OBSERVED RESULT
A momentary flash appears, but the view of the desktop remains. The game is not brought up

EXPECTED RESULT
Bring up Dota 2 in full-screen when clicking on the taskbar / panel

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.7.7-arch1-1 #1 SMP PREEMPT Wed, 01 Jul 2020 14:53:16 +0000 x86_64 GNU/Linux
KDE Plasma Version: plasma-desktop 5.19.3-1
KDE Frameworks Version: plasma-framework 5.72.0-1
Qt Version: qt5-base 5.15.0-4

ADDITIONAL INFORMATION
This appears to have started after either a system upgrade or updating Steam (or both)
Comment 1 dave knippers 2020-07-20 19:50:12 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
Comment 2 dave knippers 2020-07-20 19:53:56 UTC
one additional comment: it seems to effect only dota 2. i haven't been able to see the behaviour in other fullscreen applications.
Comment 3 Shawn 2020-07-20 22:52:08 UTC
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.
Comment 4 dave knippers 2020-07-20 22:56:53 UTC
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.
Comment 5 Shawn 2020-07-20 23:15:25 UTC
(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.
Comment 6 Bug Janitor Service 2020-07-21 09:58:16 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/126
Comment 7 Vlad Zahorodnii 2020-07-21 10:17:03 UTC
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
Comment 8 Vlad Zahorodnii 2020-07-22 13:00:50 UTC
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
Comment 9 Vlad Zahorodnii 2020-07-22 13:07:41 UTC
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