Bug 503962 - Invisible windows from other activities interference
Summary: Invisible windows from other activities interference
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: activities (other bugs)
Version First Reported In: 6.3.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-09 14:44 UTC by ben
Modified: 2025-07-29 09:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ben 2025-05-09 14:44:46 UTC
SUMMARY
Windows from non-active activity are manifesting on my current activity. They
are invisible, but they are capturing mouse-clicks / focus. Often they
are on top of the windows on the current activity I'm trying to use and I need
to move them out of the way with alt-left click (my kwin move binding) or
resize them with alt-right click to get the the windows on the current
activity. They appear to follow normal window rules, as in, I can raise the
current activity windows on top of them, move them, resize them,


STEPS TO REPRODUCE
1. reboot / login, defaults to 1st activity
2. open a window (A) (any application)
3. switch activities
4. open another window (B)  on the 2nd activity (2)
5. switch back to the first activity (1) and attempt to interact with window A

OBSERVED RESULT
Window B from activity 2 will be invisible, and "on top of" window A. It will
prevent me from focusing window A until moved out of the way.


EXPECTED RESULT
I expect each window to remain on their own activities. This was prior behavior for years.


SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Kernel Version: 6.14.5-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3050


ADDITIONAL INFORMATION
I use focus follows mouse (sloppy).
Keyboard input is not captured initially, however if I move an invisible window it becomes focused and begins capturing keybaord input.
I can query the properties of the invisible window with xprops.
The invisible windows do not show up in the taskbar, or with alt-tab, or in the desktop overview.
I can move or resize them with alt-mouse, and when I switch back to the activity they are actually on, they appear moved and resized.
If I right-click on an invisible window, I see and can use the appropriate context menu from that application.
Each of my activities has 3 virtual desktops. The invisible windows don't come
from the corresponding desktop on the other activity, but instead whichever I
last had active. That is, if I'm on activity-1-desktop-3, and I switch to
activity-2, where desktop-2 is active, the invisible windows come from activity-1-desktop-3.

Assuming the bug is in kwin, I think I first observed it when updating from (6.2.3-1 -> 6.3.2.1-4)
Or possibly (6.3.2.1-4 -> 6.3.3.1-2)
I've just updated again (6.3.3.1-2 -> 6.3.4-4) and the problem persists.
Comment 1 Shawn A. Wilson 2025-07-21 17:54:50 UTC
I am also affected by this issue after a recent KDE upgrade on Gentoo. I'm running 6.3.5 and experiencing this problem.

When switching activities, windows from the previous activity remain in the tab order in the new activity, sometimes at the top and so they intercept the mouse events until I use Alt-Tab to actually cycle through and click/move each of my current activity windows to make sure they are on top. However, the previous activity's windows can still intercept mouse clicks that are intended to go to the desktop background.

I saw this first reported here: https://bbs.archlinux.org/viewtopic.php?pid=2252863#p2252863
Comment 2 ben 2025-07-21 18:24:28 UTC
(In reply to Shawn A. Wilson from comment #1)
> I am also affected by this issue after a recent KDE upgrade on Gentoo. I'm
> running 6.3.5 and experiencing this problem.
> 
> When switching activities, windows from the previous activity remain in the
> tab order in the new activity, sometimes at the top and so they intercept
> the mouse events until I use Alt-Tab to actually cycle through and
> click/move each of my current activity windows to make sure they are on top.
> However, the previous activity's windows can still intercept mouse clicks
> that are intended to go to the desktop background.
> 
> I saw this first reported here:
> https://bbs.archlinux.org/viewtopic.php?pid=2252863#p2252863

Well, at least now I know I'm not going crazy. 
Haven't seen any traction on this issue, and never reported KDE bug before so not sure how these things get prioritized. Thanks for confirmation, should help.
FWIW I've been just keeping one desktop clear in each activity and switching to that before switching activity. Very annoying, but less maddening than the bug itself.
Comment 3 Shawn A. Wilson 2025-07-21 18:34:14 UTC
(In reply to ben from comment #2)
> FWIW I've been just keeping one desktop clear in each activity and switching
> to that before switching activity. Very annoying, but less maddening than
> the bug itself.

Thanks for the tip! Your workaround will save me some aggravation until the actual solution is in place.

FWIW, I made a note in this (older) bug too because it seems related (possibly the fixes mentioned there are what caused our problems): https://bugs.kde.org/show_bug.cgi?id=460072
Comment 4 Shawn A. Wilson 2025-07-28 15:39:22 UTC
I just upgraded KDE to 6.3.6 and I am no longer affected by the problem. Seems like it is fixed!