Quick preface; I'm not sure if this is a bug, and if it isn't I apologise. However I'm choosing to report it anyway, as it is unexpected behaviour that I'm not entirely sure if I like. The effect is nice and it works in some apps, but for web browsing it's rather in the way of things :) SUMMARY When changing tabs in Firefox, the transition between tabs use a cross-fade animation, like seen in other KDE apps such as Dolphin and the KDE Plasma System Settings app. Discord (Chromium) is also affected. I was not able to observe this in other apps, even other Chromium-based apps such as Signal and Authy. I confirmed that this is an animation controlled by Kwin/Plasma as the animation speed setting affects the fade speed. STEPS TO REPRODUCE 1. Make sure Plasma has animation speed set to anything but instant. 2. Launch Firefox (or possibly other web-browser based apps such as Discord.) 3. Open multiple tabs if you can. 4. Switch tabs or navigate to different views within the app. OBSERVED RESULT Switching between tabs/application views use a cross-fading animation. Video: https://www.youtube.com/watch?v=3_w3sXy_ewA EXPECTED RESULT Instant, non-animated transitions between browser tabs, like in Plasma 5.25.5 and older. SOFTWARE/OS VERSIONS Linux: Arch Linux, kernel 5.19 ("Linux Zen" kernel) KDE Plasma Version: Plasma 5.25.90 KDE Frameworks Version: 5.98 Qt Version: 5.15.6 ADDITIONAL INFORMATION Observed on Plasma Wayland, and thus putting this in the wayland-generic component; please move it if that is wrong. I'm not sure which component specifically handles these animations.
How weird, I don't think we put any code to cross-fade between tabs in FF. Can you post the output of `qdbus org.kde.KWin /KWin supportInformation`?
firefox must be doing asomething to trigger this effect. we have it iirc when maximizing/unmaximizing or when the color scheme changes. some of that must me happening when switching tabs. can you try to go in system settings -> desktop effects and uncheck "Maximize" to see if still happen?
Please also include output of ``` WAYLAND_DEBUG=1 firefox ``` and send us the snippet of changes when you switch tabs
Hi everyone, thank you for your responses. I just sat down to follow the steps you gave me, but for some unfortunate reason I cannot reproduce this issue anymore.. I'm unsure why it won't work now, I did try rebooting my machine when I experienced it, and it did persist after a reboot yesterday. After turning my PC on today it just works. Nevertheless, I'm supplying the requested information, and I'll leave the bug status up to you in case you want to investigate this more, or just close it now. (In reply to Marco Martin from comment #2) > can you try to go in system settings -> desktop effects and uncheck > "Maximize" to see if still happen? I tried turning it off and back on, but it works as intended now in any case. (In reply to Vlad Zahorodnii from comment #1) > How weird, I don't think we put any code to cross-fade between tabs in FF. > Can you post the output of `qdbus org.kde.KWin /KWin supportInformation`? Uploaded it here for you: https://invent.kde.org/-/snippets/2352 (In reply to David Edmundson from comment #3) > send us the snippet of changes when you switch tabs I tried generating some info from changing one tab to another using CTRL+TAB, hopefully there's not too much unnecessary info with it. https://invent.kde.org/-/snippets/2353
Just had this bug in Thunderbird's composer window a couple of minutes ago.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2988
Do you have any window rules?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2989
Git commit 7b3ae310e6d354b449d0bc198169912134069110 by Vlad Zahorodnii. Committed on 22/09/2022 at 12:16. Pushed by vladz into branch 'master'. Emit clientMaximizedStateAboutToChange when maximized mode is actually about to change Window rules code can call maximize(requestedMaximizeMode()), in which case the Window will emit clientMaximizedStateAboutToChange but the maximize mode may not actually change. This change moves the emission of of the clientMaximizedStateAboutToChange signal to Window::changeMaximize(). The reason for doing so is that window rules have the final decision what the maximize mode will be. M +0 -2 src/window.cpp M +13 -9 src/x11window.cpp M +8 -4 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/commit/7b3ae310e6d354b449d0bc198169912134069110
Git commit 82cf6f3c2d8009b65f8152d31d02b313931ad00a by Vlad Zahorodnii. Committed on 22/09/2022 at 12:36. Pushed by vladz into branch 'Plasma/5.26'. Emit clientMaximizedStateAboutToChange when maximized mode is actually about to change Window rules code can call maximize(requestedMaximizeMode()), in which case the Window will emit clientMaximizedStateAboutToChange but the maximize mode may not actually change. This change moves the emission of of the clientMaximizedStateAboutToChange signal to Window::changeMaximize(). The reason for doing so is that window rules have the final decision what the maximize mode will be. (cherry picked from commit 7b3ae310e6d354b449d0bc198169912134069110) M +0 -2 src/window.cpp M +13 -9 src/x11window.cpp M +8 -4 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/commit/82cf6f3c2d8009b65f8152d31d02b313931ad00a
I believe this bug should be fixed with the patch above.
(In reply to Vlad Zahorodnii from comment #7) > Do you have any window rules? Yes, quite a lot, however none of them are for Firefox. Discord's window rule only changes its titlebar colour, as do many of the others. Nice work by the way!!