Bug 501393 - Window focus is lost after activity switch when using multiple activities and screens (Plasma 6.3.2, Frameworks 6.1.1, Qt 6.8.2)
Summary: Window focus is lost after activity switch when using multiple activities and...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: activities (other bugs)
Version First Reported In: 6.3.3
Platform: Manjaro Linux
: NOR grave
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 501397 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-03-12 07:49 UTC by Regényi Balázs
Modified: 2025-07-09 21:38 UTC (History)
9 users (show)

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


Attachments
Screenshot of browser with "text input cursor" from other app (42.66 KB, image/png)
2025-03-19 13:46 UTC, Kevin Krammer
Details
Screenshot of browser with tooltip/hover info from Kate (56.96 KB, image/png)
2025-03-19 13:48 UTC, Kevin Krammer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regényi Balázs 2025-03-12 07:49:45 UTC
SUMMARY
After switching between activities, window focus is lost. Clicking on a window in the newly active activity does not bring it to focus. It feels like the previously active window from the previous activity remains active, even though it is no longer visible. To fix focus temporarily, I need to click an application in the taskbar on the current activity.

STEPS TO REPRODUCE
1. Set up at least two activities.
2. Open windows in each activity (for example, Firefox in Activity 1, Dolphin in Activity 2).
3. Switch between activities using keyboard shortcuts or the activity switcher.

OBSERVED RESULT
After switching to another activity, clicking on a visible window does not focus it. The window from the previous activity remains the active window (although it is not visible). I have to click on an application in the taskbar to make it active and get proper focus behavior back.

EXPECTED RESULT
After switching activities, clicking on a window in the current activity should immediately give focus to that window, without needing to click on the taskbar first.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro Linux (fully up to date as of early March 2025)
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.1.1
Qt Version: 6.8.2

ADDITIONAL INFORMATION
- Using multiple screens (two monitors).
- Each screen has independent windows.
- Multiple virtual desktops (workspaces) are in use.
- "Click to focus" is set as the window focus policy.
- Issue started after a major update about one week ago.
- Running on X11.
Comment 1 Enrique 2025-03-14 18:07:12 UTC
I have this same issue as well.

Similar software and os version too.
SOFTWARE AND OS VERSIONS
Plasma: 6.3.2
KDE Framework: 6.11.0
Qt: 6.8.2
Kernel: 6.12.17-1 MANJARO
X11
Comment 2 Manfred Musch 2025-03-19 11:03:06 UTC
In my case the same behaviour, but with a different distribution. However, I'm not to 100% sure whether it goes hand in hand with the use of Activities. But it could be the case. By the way, to be clear, I'm using Activities (five, to be more precise - with four workspaces on each).
-----
Operating System: openSUSE Tumbleweed 20250317
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.12.0
Qt Version: 6.8.2
Kernel Version: 6.13.6-1-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 PRO 4650G with Radeon Graphics
Memory: 14.9 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: CSL Computer GmbH
Comment 3 Kevin Krammer 2025-03-19 13:46:01 UTC
Created attachment 179573 [details]
Screenshot of browser with "text input cursor" from other app

The window shown is Chromium (on discuss.kde.org)
The cursor is indicating text input which the current window does not have at this location.

On another activity I had Kate at that same position on that same monitor.
Different virtual desktop though, but it was the desktop that KWin "remembered" for that activity.
Comment 4 Kevin Krammer 2025-03-19 13:48:38 UTC
Created attachment 179574 [details]
Screenshot of browser with tooltip/hover info from Kate

Identical situation to the other screenshot but here I hovered over the position at which the Kate window would have its "scrollbar" so it triggered its hover effect.

Essentially happened accidentally while taking the other screenshot, which made me realize that the other window was Kate and that it was on a different activity
Comment 5 Kevin Krammer 2025-03-19 13:58:24 UTC
This was most likely introduced in 6.3 with the change that moved "remember virtual desktop on activity" from Activity Manager to KWin.

It now remembers the activity so well that the previous activity's windows still get the mouse input.

At first I couldn't find a pattern but only had very unresponsive windows and weird changes to windows I had not explicitly interacted with.

The latter effect is now clearly the result of the visible window being "unresponsive" because it received the clicks, moves, drags that the visible window appeared to ignore.

If the "other window" is fullscreen you can't even intact with Plasma on the new activity anymore.

Only reliable way to interact with any window is to go through an explicit KWin activation (ALT-Tab, window overview, taskbar activation).
Anything else is the mouse interaction equivalent of Russian Roulette.

I am increasing severity and moving to component activities

P.S.: platform info
Operating System: KDE neon 6.3
KDE Plasma Version: 6.3.3
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.11.0-19-generic (64-bit)
Graphics Platform: X11
Comment 6 Nate Graham 2025-03-19 18:27:57 UTC
X11-only bugs aren't HI or VHI anymore; lowering priority.

Still worth fixing of course.
Comment 7 Luke Horwell 2025-03-28 12:17:08 UTC
*** Bug 501397 has been marked as a duplicate of this bug. ***
Comment 8 Kevin Krammer 2025-04-30 13:57:56 UTC
I've found a workaround.

If you always switch activity on the same virtual desktop then the problem does not happen.

For example I will now always first switch to virtual desktop 1 before switching activities.

The new "remember virtual desktop" behavior requires me to change virtual desktops anyway, either before or after switching activities.
If I do it before I don't get hit by this bug either.

With the split of repositories it might be worthwhile to consider removal of this new behavior from kwin_x11 and keep stabilizing it in kwin_wayland first. Ideally with an on/off switch before "backporting" it to kwin_x11 (if at all)?
Comment 9 Lorenzo 2025-05-12 15:15:10 UTC
I'm also hit by this:
Plasma 6.3.4
KDE Framework 6.13.0
Manjaro with X11

The same virtual desktop workaround doesn't work form me as I'm having two virtual desktops per activity, which is kind of the point of having activities for me, i.e. having an additional 'dimension' on top of virtual desktops (I imagine virtual desktops like being the X of switching and activities the Y...)

A really annoying workaround for me is after switching also doing e.g. META + D two times (show / hide desktop) or a couple of ALT+ TAB to re-focus the correct window.
This is particularly painful when working with browsers or file managers as you accidentally click on a hyperlink in the 'old' window.
Comment 10 Lorenzo 2025-05-13 07:48:02 UTC
I've actually tested this with Wayland session and this is even more annoying IMHO.

When keyboard cycling through an activity with different virtual desktops on each activity the virtual desktop switching 'animation' is triggered and still the focus is on the 'old' window.

So it seems that this is not an X11 bug only (which seemed to be hinted from some comments).
Comment 11 Lorenzo 2025-05-13 07:51:38 UTC
(In reply to Lorenzo from comment #10)
> I've actually tested this with Wayland session and this is even more
> annoying IMHO.
> 
> When keyboard cycling through an activity with different virtual desktops on
> each activity the virtual desktop switching 'animation' is triggered and
> still the focus is on the 'old' window.
> 
> So it seems that this is not an X11 bug only (which seemed to be hinted from
> some comments).
So this creates two major annoyances and rather unusable UX:
- the virtual desktop switching 'animation' ('fade desktop' in my case) is triggered
- if I click on what I think is the window in focus on the activity / desktop because focus is on the old one everything 'jumps' back to that activity/desktop/window
Comment 12 ksm0816 2025-05-27 15:36:04 UTC
Would it be possible to raise the priority of this bug since

* this apparently also happens on Wayland, and
* it makes Plasma completely unusable if you use virtual desktops and activities?
Comment 13 Regényi Balázs 2025-06-30 10:46:20 UTC
(In reply to Regényi Balázs from comment #0)
> ...
> - Running on X11.

I have now switched to Wayland, and the exact same issue still occurs. This confirms that the focus bug is not limited to X11.

Current system info:
Operating System: Manjaro Linux
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.1
Kernel Version: 6.15.3-1-MANJARO (64-bit)
Graphics Platform: Wayland
CPU: Intel Core i5-1245U
RAM: 31 GiB
GPU: Intel Graphics
Device: Dell Latitude 5430

A possible workaround:
After switching activities, pressing Ctrl+D twice (my shortcut for "Show Desktop") restores proper focus behavior. So:
- Switch activity
- Press Ctrl+D twice
  → Now window focus works normally again.

Let me know if I can help with debugging or if logs would be useful.
Comment 14 Bug Janitor Service 2025-07-03 17:03:15 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7869
Comment 15 Zamundaaa 2025-07-03 17:31:04 UTC
Git commit f67619be3e44633ef57c37561c9c9edfbb53d8a0 by Xaver Hugl, on behalf of Xaver Hugl.
Committed on 03/07/2025 at 17:02.
Pushed by zamundaaa into branch 'Plasma/6.4'.

workspace: Fix window activation on activity change


(cherry picked from commit 4b89e0be728a660dbc6f617d032e4fb0055667ad)

Co-authored-by: Dorian OUAKLI <dorian.ouakli@xwiki.com>

M  +34   -96   src/workspace.cpp
M  +1    -0    src/workspace.h

https://invent.kde.org/plasma/kwin/-/commit/f67619be3e44633ef57c37561c9c9edfbb53d8a0
Comment 16 Dorian OUAKLI 2025-07-03 19:34:50 UTC
Git commit 4972183b5456856e6445708f0cb4e58e31728fe4 by Dorian OUAKLI.
Committed on 03/07/2025 at 17:58.
Pushed by zamundaaa into branch 'Plasma/6.3'.

workspace: Fix window activation on activity change

M  +19   -81   src/workspace.cpp
M  +1    -0    src/workspace.h

https://invent.kde.org/plasma/kwin/-/commit/4972183b5456856e6445708f0cb4e58e31728fe4
Comment 17 Dorian OUAKLI 2025-07-07 14:02:35 UTC
Git commit 613966782e382b0337547975791bca3e9de1c7a9 by Dorian OUAKLI.
Committed on 04/07/2025 at 00:11.
Pushed by vladz into branch 'master'.

workspace: Fix window activation on activity change

M  +19   -81   src/workspace.cpp
M  +1    -0    src/workspace.h

https://invent.kde.org/plasma/kwin-x11/-/commit/613966782e382b0337547975791bca3e9de1c7a9
Comment 18 Vlad Zahorodnii 2025-07-07 14:26:42 UTC
Git commit b1cf932e0d19230e7a119410b7fb572d2dd5c7c2 by Vlad Zahorodnii, on behalf of Dorian OUAKLI.
Committed on 07/07/2025 at 14:03.
Pushed by vladz into branch 'Plasma/6.4'.

workspace: Fix window activation on activity change

M  +19   -81   src/workspace.cpp
M  +1    -0    src/workspace.h

https://invent.kde.org/plasma/kwin-x11/-/commit/b1cf932e0d19230e7a119410b7fb572d2dd5c7c2