Summary: | Windows from another desktop are being rendered on top of current one | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Kiril Vladimirov <kiril> |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arthur.poulet.kde, butmonkeh, isma.af, miranda, nate, stunts |
Priority: | NOR | Keywords: | regression |
Version: | 5.25.0 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/commit/21dbc3c973c2deb2768789507e8b40a07b7ac8e0 | Version Fixed In: | 5.25.1 |
Sentry Crash Report: |
Description
Kiril Vladimirov
2022-06-14 09:54:17 UTC
I can't reproduce it. Can you provide more detailed steps to reproduce? Does firefox run with native wayland support? What should one do in step 3? I can reproduce it, but only when some Window Rule regarding virtual desktops is applied. Do you have any rules set on this particular window? > Do you have any rules set on this particular window?
Totally forgot about it. I have a window rule to always open Firefox on desktop 1. Deleting it fixed the issue.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2521 I, too, am seeing this issue, but only sporadically on certain boots about a fifth of the time. I have no indication how to reproduce this besides rebooting and crossing my fingers. In my situation I have no window rules and have not made any adjustments to default window management behavior. In an attempt to fix this I had tried clearing my entire .local and .config directory's k* and plasma* files/folders, starting with a fresh KDE experience for my user. Unfortunately, the issue returned. The only notable adjustments made were adding a taskbar to my secondary monitor and creating multiple horizontal virtual desktops. Forgot to add my setup: Linux 5.18.3 Arch rolling release Qt 5.15.4 KDE Frameworks 5.95.0 Plasmashell 5.24.90 Nvidia proprietary driver 515.48.07 Git commit 1725e224839ba5a703fa24299dbbd438bf63fd94 by Vlad Zahorodnii. Committed on 15/06/2022 at 06:48. Pushed by vladz into branch 'master'. effects/slide: Ensure that there's only one visibility ref per window If a window is added and then the current virtual desktop changes, we can encounter the following situation: * desktopChanged signal is emitted, and the slide effect starts animation. SlideEffect::prepareSwitching() will setup windows; note that the new window may be present in effects->stackingOrder() * windowAdded signal is emitted, and slide effect tries to ref the window again In order to ensure that there's only one reference, maintain visibility refs in a hashtable. M +12 -3 src/effects/slide/slide.cpp M +6 -0 src/effects/slide/slide.h https://invent.kde.org/plasma/kwin/commit/1725e224839ba5a703fa24299dbbd438bf63fd94 Git commit 21dbc3c973c2deb2768789507e8b40a07b7ac8e0 by Vlad Zahorodnii. Committed on 15/06/2022 at 07:10. Pushed by vladz into branch 'Plasma/5.25'. effects/slide: Ensure that there's only one visibility ref per window If a window is added and then the current virtual desktop changes, we can encounter the following situation: * desktopChanged signal is emitted, and the slide effect starts animation. SlideEffect::prepareSwitching() will setup windows; note that the new window may be present in effects->stackingOrder() * windowAdded signal is emitted, and slide effect tries to ref the window again In order to ensure that there's only one reference, maintain visibility refs in a hashtable. (cherry picked from commit 1725e224839ba5a703fa24299dbbd438bf63fd94) M +12 -3 src/effects/slide/slide.cpp M +6 -0 src/effects/slide/slide.h https://invent.kde.org/plasma/kwin/commit/21dbc3c973c2deb2768789507e8b40a07b7ac8e0 *** Bug 447876 has been marked as a duplicate of this bug. *** *** Bug 455531 has been marked as a duplicate of this bug. *** *** Bug 455879 has been marked as a duplicate of this bug. *** |