Bug 455237

Summary: Windows from another desktop are being rendered on top of current one
Product: [Plasma] kwin Reporter: Kiril Vladimirov <kiril>
Component: wayland-genericAssignee: 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: Version Fixed In: 5.25.1

Description Kiril Vladimirov 2022-06-14 09:54:17 UTC
SUMMARY
After upgrading to 5.25.0 (Fedora Rawhide), upon changing a desktop _particular_ windows from the previous desktop are being rendered on top of current one. The window is not responding to any interactions whatsoever. Looks like it's just being rendered there. Re-focusing windows seems to work and the one actually on current desktop get precedence, but the desktop is never visible until the ghost one gets minimized or closed.

Saying "particular" because it seems to be happening only with windows of some apps. Consistently happens with Firefox for instance. It doesn't seem to happen with Dolphin and Konsole, though. 

A recording might make the issue easier to grasp: https://drive.proton.me/urls/RTKT32T20C#0sfFTbgP5rKI

STEPS TO REPRODUCE
1. Open some windows on one desktop.
2. Open Firefox on another.
3. Switch to the desktop from step 2 to step 1

OBSERVED RESULT
Firefox is rendered on top of everything, even though once can not interact with. 

EXPECTED RESULT
Firefox should not be visible given that it's not on the switched to desktop.

SOFTWARE/OS VERSIONS
Linux 5.17.13
KDE Plasma Version: 5.25.0
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
This is a regression after updating to 5.25 on my machine. I've never experienced an issue anywhere near that on 5.24 and below.
Comment 1 Vlad Zahorodnii 2022-06-14 10:02:48 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?
Comment 2 Ismael Asensio 2022-06-14 13:07:09 UTC
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?
Comment 3 Kiril Vladimirov 2022-06-14 15:23:52 UTC
> 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.
Comment 4 Bug Janitor Service 2022-06-14 16:24:27 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2521
Comment 5 miranda 2022-06-14 21:20:17 UTC
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.
Comment 6 miranda 2022-06-14 21:23:14 UTC
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
Comment 7 Vlad Zahorodnii 2022-06-15 07:04:32 UTC
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
Comment 8 Vlad Zahorodnii 2022-06-15 07:10:23 UTC
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
Comment 9 Ismael Asensio 2022-06-18 09:07:49 UTC
*** Bug 447876 has been marked as a duplicate of this bug. ***
Comment 10 Ismael Asensio 2022-06-18 09:09:47 UTC
*** Bug 455531 has been marked as a duplicate of this bug. ***
Comment 11 Nate Graham 2022-06-24 13:55:57 UTC
*** Bug 455879 has been marked as a duplicate of this bug. ***