Created attachment 149817 [details] recording SUMMARY After updating to Plasma 5.25, kwin has started composing windows in the wrong order sometimes, as shown in the attached video. It's not entirely, consistent, but it tends to happen if i click a window on one desktop, scroll to another desktop and click a window there, and then scroll to another desktop where I have multiple windows open and click one of them in the taskbar. It only works a few times with a given set of windows, but when it stops working with those windows, I can switch to a different set of windows to trigger it again. While it's happening, the active window will go behind the previous window rather than in front of it. It will still receive mouse input though, so you end up interacting with it through another window. This affects all windows once it's been triggered. It then stops if I toggle compositing (alt+shift+f12). As soon as I disable compositing, the active window pops up to the front. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220613 KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.18.2-1-default (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 Gibyte of RAM Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 Manufacturer: ASUS
Created attachment 149954 [details] Window list behind control panel
Created attachment 149955 [details] Kickoff behind window
Created attachment 149956 [details] Window list started by shortcut
Same strange behaviour on my system. Only if I change windows two times with cover switch or flip switch then I have the normal behaviour - but not for long. I'm using 5 activities and 4 workspaces for different purposes (however mostly not always all of them at the same time), but that's not the reason for this behaviour because it also occurs with only one activity in use. Perhaps a similar phenomenon: in some cases the window list disappears behind the control panel, and even so kickoff which is theoretically in the foreground but behind an opened window (see screenshots 1 and 2). For window list even stranger: if I use a shortcut to start the list it looks totally different (see screenshot 3). Infos software / hardware: Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.0 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 Kernel Version: 5.13.0-51-generic (64-bit) Graphics Platform: X11 Processors: 4 × AMD A8-6600K APU with Radeon(tm) HD Graphics Memory: 7.0 GiB of RAM Graphics Processor: AMD ARUBA
It looks like compositing stacking order differs from the real one, although I can't reproduce this issue. What do you do to reproduce this bug?
(In reply to Vlad Zahorodnii from comment #5) > It looks like compositing stacking order differs from the real one, although > I can't reproduce this issue. What do you do to reproduce this bug? That's the problem, I can't say: first this step, then the next, and then it goes wrong... It seems that it has to do with changing workspaces and/or activities (say three workspaces with some windows opened, then moving between them, changing windows on one workspace, going back), but I can't describe a precise pattern (how much windows, how much workspaces and/or activities). And it only occurs after a certain time (not too much time however). So my only possibility to reproduce is to wait until it is the case... Not very satisfactory as an answer, I know. I haven't changed any settings between Plasma 5.24.5 and 5.25, it only has occurred (and occurs) in 5.25. Perhaps I should let run after a fresh start a screencast alongside to get a hint?
(In reply to Vlad Zahorodnii from comment #5) > It looks like compositing stacking order differs from the real one, although > I can't reproduce this issue. What do you do to reproduce this bug? Now I think I have found the "moment"! I started with a new session, first in the standard activity. There I opened on first workspace a program (Kontact - which by the way I like very much), then I switched to workspace 2 and opened two programs (in my case Falkon and Firefox, but it doesn't matter). Then workspace 3 with three programs, moving one of these programs to workspace 2. Then switching to workspace opening two new programs (Konsole and Gwenview). All is working perfect insofar. And now comes the point. I switch to a second activity, start there in one of my four workspaces two programs and in a second workspace another program (the number of programs shouldn't play that role, but I only mention it to reproduce my way - and I think it is a real-case scenario for working). So far so good. But then: I switch back to the first standard activity, workspace 1 (with the three programs) - and I have the problems. It has obviously to do with switching between activities. I have read what other users have written, and I think it was the same with then: the moving between activities if you have opened programs/windows in other activities. I hope that helps. By the way: activities are a great concept. One of the main reasons I'm using KDE Plasma intensively. The best way in my eyes to adapt your pc work to your own needs!
(In reply to Vlad Zahorodnii from comment #5) > It looks like compositing stacking order differs from the real one, although > I can't reproduce this issue. What do you do to reproduce this bug? Short correction: the two new programs mentioned in my post (Konsole and Gwenview) were started in the first workspace of the standard activity - I had the 1 omitted (but you will have noticed it). And a small addition: as soon as the window management is no longer in order, the program list also slips behind the control panel. Both problems seem connected!
I also now had a case where one window was rendered on every desktop. The window was on one desktop, but if you switched to a different desktop where the window wasn't supposed to be, any desktop, the window would pop up there too after a second or so, but not be interactive. Similar to the other issue, toggling compositing resolved it.
Created attachment 150060 [details] Broken Activities demonstrated To reproduce how program windows are active behind inactive windows that can't be easily pushed into the background I have made a little screencast. I was able to reproduce this behaviour several times without difficulty. The effect occurred even faster than I remembered. The steps described: (1) open one window in standard activity; (2) switch to a second activity and open two windows in the same workspace there; (3) go back to standard activity and open a second window there in the same workspace as before; (4) the effect occurs. And as you can see: the control panel is also affected. By the way: the new window list is almost unusable because it has no fixed width in the panel - sometimes it's narrow and sometimes it's wide. In KDE 3.5 it was a simple button in the panel (so in Plasma 5.24 too), and the entries could be seen when you clicked on the button...
(In reply to Manfred Musch from comment #10) > Created attachment 150060 [details] > Broken Activities demonstrated > > To reproduce how program windows are active behind inactive windows that > can't be easily pushed into the background I have made a little screencast. > I was able to reproduce this behaviour several times without difficulty. The > effect occurred even faster than I remembered. The steps described: (1) open > one window in standard activity; (2) switch to a second activity and open > two windows in the same workspace there; (3) go back to standard activity > and open a second window there in the same workspace as before; (4) the > effect occurs. And as you can see: the control panel is also affected. By > the way: the new window list is almost unusable because it has no fixed > width in the panel - sometimes it's narrow and sometimes it's wide. In KDE > 3.5 it was a simple button in the panel (so in Plasma 5.24 too), and the > entries could be seen when you clicked on the button... It looks like you have slide back effect enabled. What if you disable it? Can you still reproduce the issue?
(In reply to Vlad Zahorodnii from comment #11) > (In reply to Manfred Musch from comment #10) > > Created attachment 150060 [details] > > Broken Activities demonstrated > > > > To reproduce how program windows are active behind inactive windows that > > can't be easily pushed into the background I have made a little screencast. > > I was able to reproduce this behaviour several times without difficulty. The > > effect occurred even faster than I remembered. The steps described: (1) open > > one window in standard activity; (2) switch to a second activity and open > > two windows in the same workspace there; (3) go back to standard activity > > and open a second window there in the same workspace as before; (4) the > > effect occurs. And as you can see: the control panel is also affected. By > > the way: the new window list is almost unusable because it has no fixed > > width in the panel - sometimes it's narrow and sometimes it's wide. In KDE > > 3.5 it was a simple button in the panel (so in Plasma 5.24 too), and the > > entries could be seen when you clicked on the button... > > It looks like you have slide back effect enabled. What if you disable it? > Can you still reproduce the issue? Now I disabled the slide back effect - and the issue disappeared! Thanks for the very helpful tip! Much better the activities work normally again than to insist on the slide back effect... Of course there must be a reason that this confusing behaviour occurred with the change from 5.24 to 5.25, and the slide back effect had the advantage that it could be used as an additional clearly visible sign for changing overlapping windows - but I'm already satisfied that my activities workflow is restored! Your assumption was completely right!
*** Bug 456873 has been marked as a duplicate of this bug. ***
*** Bug 458142 has been marked as a duplicate of this bug. ***
I also encountered this issue when enabling the slide back effect - the active window is shown behind the previously active window. Also menus (from the main menu or an RMB menu) show behind the active window so they are almost entirely non-operatable. Disabling the slide back effects reverts to the correct behavior.
*** Bug 464494 has been marked as a duplicate of this bug. ***
Created attachment 156892 [details] Right-click menu not showing up inside firefox I had such a difficult time reproducing this bug, let alone recording it. I also had no idea how to describe it except by calling it a window stacking issue. In the video, blue mouse splash is right-click, and as you can see, it works on the desktop, but not in an application like firefox. Also note that towards the end of the video, I had use Alt+Tab to switch windows, and suddenly, it looks like that fixed the issue. However, what you didn't get to see is that my screen recorder window became unresponsive and I could not click any buttons on it, so I had to manually kill it. I only started noticing this issue since the 5.27 update. It seems that the recommendation of disabling the slide-back effect may have something to do with fixing it, but I'm not quite convinced as I had tried this a couple days ago, without success. Now that I know I'm not alone in this, I will keep an eye out if it occurs again and will promptly report here.
(In reply to FirstAirBender from comment #18) > In the video, blue mouse splash is right-click, and as you can see, it works > on the desktop, but not in an application like firefox. From my experience with this issue, I think it is clear that what happens when you right-click Firefox, is that the RMB menu appears behind the Firefox window - which is maximized so you can't see the menu. If you set up Firefox to not cover the whole desktop and right click towards an edge where the desktop is showing, you'd be able to see part of the RMB menu that appears. Same with the kickoff menu that you're showing also trying to open and it not being displayed - the highlight clearly shows that it opens - but it is behind the Firefox window and so not accessible. I don't know why the save dialog was not response - it could be that it was rendered on top but was considered at the bottom due to problematic window stacking issue. I haven't used the slide-back effect for a while (due to this issue) and have since moved to Wayland. I'll re-enable it and see how problematic it is on Wayland.
Created attachment 157034 [details] Screencast showing menus behind windows on Wayland I can reproduce the issue on Wayland - after less than a day of having the Slide back effect enabled, the Kwin Wayland compositor started misbehaving, as can be seen on the video: the Kickoff menu and desktop RMB menus are showing behind all the windows, and the active Window is behind the non-active window. Outside the screencast, I also had the Yakuake window (which is window-ruled to be always on top) appear behind all other windows, and its window operation menu showing above the Yakuake window but behind all other windows. The problematic behavior could be reset for specific windows by opening and closing the window operations menu for the window that is visually on top, but that fixes the problem only for that specific window and it can get rebroken pretty easily by opening another window. After disabling the Slide back effect, the desktop did not immediately recover - all the windows that were showing "out of order" were still out of order until I opened and closed the window operations menu for all of them.
Created attachment 157035 [details] Screencast showing menus behind windows on Wayland Replacing screencast with a more browser-friendly h264 version.
*** Bug 458446 has been marked as a duplicate of this bug. ***
*** Bug 468389 has been marked as a duplicate of this bug. ***
*** Bug 475088 has been marked as a duplicate of this bug. ***