THIS IS NOT SEVERE OR ANYTHING, BUT THIS IS SOMETHING THAT HAS BEEN KINDA UNCOMFORTABLE STEPS TO REPRODUCE 1. Open any program/app (e.g: Konsole, Spotfiy, Firefox etc.) 2. Press the minimize button. OBSERVED RESULT The bouncing icon should appear next to the cursor for a few seconds before disappearing EXPECTED RESULT Minimizing should not the bouncing icon next to the mouse REGRESSION Yes. This wasn't a problem in KDE Plasma 6.5.91 Appear after updating to KDE Plasma 6.6.0 SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 43 (KDE Plasma Desktop Edition) KDE Plasma Version: 6.6.0 KDE Frameworks Version: 6.23.0 Qt Version: 610.1 Kernel Version 6.18.10-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland HARDWARE INFORMATION: Processors: 16 x AMD Ryzen 7 7735HS with Radeon Graphics Memory: 16 GiB of RAM (14.9 GiB usable) Graphics Processor 1: AMD Radeon 680M (INTERGRATED) Graphics Processor 2: AMD Radeon RX 7700S (DISCRETE) ADDITIONAL INFORMATION This isn't really a problem for me, but rather it looks really awkward when minimizing, I frequently use the minimize button and it messes with my head since I kept thinking it was loading something in the background. But eventually got used to it.
I can't reproduce this Operating System: KDE Linux 2026-02-19 KDE Plasma Version: 6.6.80 KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2 Kernel Version: 6.18.9-zen1-2-zen (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
I can't reproduce this issue (and have never seen a similar one)
UPDATE: Turns out this wasn't a KDE Update problem, but rather a Appearance & Style problem. Under Colours & Themes > Windows Decorations, if you use Plastik over Breeze, it will cause this problem. Weirdly enough if the system is in light mode, it will sometimes appear, but if in dark mode it will be a guaranteed that the bouncing icon will happen.
(In reply to Abrerser from comment #3) > UPDATE: Turns out this wasn't a KDE Update problem, but rather a Appearance > & Style problem. Under Colours & Themes > Windows Decorations, if you use > Plastik over Breeze, it will cause this problem. Weirdly enough if the > system is in light mode, it will sometimes appear, but if in dark mode it > will be a guaranteed that the bouncing icon will happen. Oh wow, yeah, I can reproduce it with Plastik.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9314
Git commit fa4106c8fec957f81f89b9b27fe30de9449043bc by Vlad Zahorodnii. Committed on 05/06/2026 at 12:30. Pushed by vladz into branch 'master'. Check whether a transient of an inactive window can be activated differently Since the ActivateRaiseOnReleaseAndPassClick action is no longer applied when you click a decoration button, the window will remain inactive when you press a decoration button. Since the window is inactive and an activation token gets generated for button events, it's possible that the app icon will start bounce. This issue can also be observed when you use the Plastik decoration theme and minimize an inactive window. However, with the recent changes, this bug can be observed with Breeze too. The culprit is that we want "save changes" dialogs of inactive windows to be activated after the user clicks the close button. At the moment, kwin generates an activation token for every button press and release if the corresponding event is not handled by the decoration. However, the activation tokens are generated with app ids so they are interpreted as if they are used to launch an app. This change takes a slightly different approach to solve that case. We can check usage serials. It's less precise but the current solution is fuzzy as well. As a bonus, it makes sure that the transient of an inactive parent heuristic is going to work with all supported input device types, not just pointers. M +6 -3 src/activation.cpp M +0 -7 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/fa4106c8fec957f81f89b9b27fe30de9449043bc
Git commit f6df264a13fc34cb854e22117069aca05790a558 by Vlad Zahorodnii. Committed on 05/06/2026 at 13:55. Pushed by vladz into branch 'Plasma/6.7'. Check whether a transient of an inactive window can be activated differently Since the ActivateRaiseOnReleaseAndPassClick action is no longer applied when you click a decoration button, the window will remain inactive when you press a decoration button. Since the window is inactive and an activation token gets generated for button events, it's possible that the app icon will start bounce. This issue can also be observed when you use the Plastik decoration theme and minimize an inactive window. However, with the recent changes, this bug can be observed with Breeze too. The culprit is that we want "save changes" dialogs of inactive windows to be activated after the user clicks the close button. At the moment, kwin generates an activation token for every button press and release if the corresponding event is not handled by the decoration. However, the activation tokens are generated with app ids so they are interpreted as if they are used to launch an app. This change takes a slightly different approach to solve that case. We can check usage serials. It's less precise but the current solution is fuzzy as well. As a bonus, it makes sure that the transient of an inactive parent heuristic is going to work with all supported input device types, not just pointers. (cherry picked from commit fa4106c8fec957f81f89b9b27fe30de9449043bc) M +6 -3 src/activation.cpp M +0 -7 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/f6df264a13fc34cb854e22117069aca05790a558