Bug 483148 - TM context menu "Move to [activity name]" doesn't move window, and instead shows window on all activities
Summary: TM context menu "Move to [activity name]" doesn't move window, and instead sh...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager widgets (other bugs)
Version First Reported In: 6.0.1
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: qt6
: 502620 505196 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-03-10 18:15 UTC by bastimeyer123
Modified: 2025-06-05 17:51 UTC (History)
7 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bastimeyer123 2024-03-10 18:15:37 UTC
SUMMARY
The "Move to [activity name]" which was implemented in Plasma 5.24 has stopped working in Plasma 6.

Instead of moving the window to the specific activity, the window gets shown on all activities. This is only the case though if the window hasn't been shown on all activities in the first place.

Only tested on Wayland...

STEPS TO REPRODUCE
1. Set up activity A and B
2. Open any GUI application on activity A
3. Right click the task manager's item -> "Show in activities" -> "Move to activity B"

OBSERVED RESULT
Application window is shown on both activity A and B

EXPECTED RESULT
Window should only be shown on activity B

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0 
Qt Version: 6.6.2
Comment 1 Nate Graham 2024-03-11 21:27:57 UTC
Does the equivalent menu item in the window context menu suffer from the same issue? Or does that one work for you?
Comment 2 bastimeyer123 2024-03-11 21:43:41 UTC
(In reply to Nate Graham from comment #1)
> Does the equivalent menu item in the window context menu suffer from the
> same issue? Or does that one work for you?

No, that one works as expected and moves the window to the other activity. Only the task manager context menu seems to be affected by this bug.
Comment 3 Nate Graham 2024-03-13 18:55:08 UTC
Can reproduce that issue.
Comment 4 edrics 2024-11-21 09:02:27 UTC
Still present in Plasma: 6.2.3, I will add two observations:

1. The bug seems to exist only when there are just two activities. I created a third activity to check if the window appears on all activities or just the starting and target ones: suddenly windows can be moved without bugs between activities, as expected using this action.

2. When there are only two activities, the bug acts as described. I will just add  that using the "move to activity" action twice has the desired effect: the first time it shows it in both activities, the second time the window disappears from the starting activity and remains only in the target one. It is like selecting "show in all activities" and then de-selecting the starting activity.

Can anyone confirm these behaviours?
Comment 5 Bruno Massa 2024-12-16 03:29:42 UTC
WOW, exactly like that! I've never created a 3rd activity, but when I did, the "move to" just worked.
Comment 6 Nate Graham 2025-04-09 17:44:20 UTC
*** Bug 502620 has been marked as a duplicate of this bug. ***
Comment 7 luk 2025-06-04 11:14:22 UTC
still present in Plasma 6.3.5
Comment 8 cwo 2025-06-04 16:24:25 UTC
*** Bug 505196 has been marked as a duplicate of this bug. ***
Comment 9 Bug Janitor Service 2025-06-04 20:32:28 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5567
Comment 10 bastimeyer123 2025-06-04 22:46:26 UTC
(In reply to Bug Janitor Service from comment #9)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5567

I've applied the commit from the MR to my plasma-workspace build and can confirm that this fixes the issue.
Comment 11 cwo 2025-06-05 15:17:56 UTC
Git commit 99f9dc95226719c2be53fd86a4a0a3bae88d0aa2 by Christoph Wolk.
Committed on 05/06/2025 at 14:39.
Pushed by cwo into branch 'master'.

libtaskmanager: fix "move to activity" when on almost all activities

Using the task manager to move windows to other activities works in
most circumstances, but fails under one condition: when a window is
already on all activities except the one that is being moved to, the
window instead ends up on all activities, and has to be moved to that
activity again to be only on that workspace. This is usually a rare edge
case, but very commonly happens when using exactly two activities,
namely always when moving a window from one activity to the other.

This is the result of some unusual api implementation details of
activities: a window being on all activities is represented by having
the activity list for that window empty. Moving a window to a different
activity in  libtaskmanager is done by first adding the window to the
activity list using the plasma wayland protocol. If the list on the kwin
side is now  full, it'll flip it over into the empty list (i.e. all
activities). Next libtaskmanager tries to remove the other activities
from the list, this fails because the list is already empty (and kwin
doesn't handle this because "this use case is not important enough to
handle here").

Luckily enough, this use case is trivially easy to handle here, all we
need to do is remove existing activities first, then add the new one.
This will also briefly put it on all activities, but adding new
activities works (and puts it only on that activity), it's only
removing them that fails.
FIXED-IN: 6.4.0

M  +5    -5    libtaskmanager/waylandtasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/99f9dc95226719c2be53fd86a4a0a3bae88d0aa2
Comment 12 cwo 2025-06-05 17:51:07 UTC
Git commit e2ae8f54b0390b869770f59c257d45df99b24678 by Christoph Wolk.
Committed on 05/06/2025 at 15:18.
Pushed by cwo into branch 'Plasma/6.4'.

libtaskmanager: fix "move to activity" when on almost all activities

Using the task manager to move windows to other activities works in
most circumstances, but fails under one condition: when a window is
already on all activities except the one that is being moved to, the
window instead ends up on all activities, and has to be moved to that
activity again to be only on that workspace. This is usually a rare edge
case, but very commonly happens when using exactly two activities,
namely always when moving a window from one activity to the other.

This is the result of some unusual api implementation details of
activities: a window being on all activities is represented by having
the activity list for that window empty. Moving a window to a different
activity in  libtaskmanager is done by first adding the window to the
activity list using the plasma wayland protocol. If the list on the kwin
side is now  full, it'll flip it over into the empty list (i.e. all
activities). Next libtaskmanager tries to remove the other activities
from the list, this fails because the list is already empty (and kwin
doesn't handle this because "this use case is not important enough to
handle here").

Luckily enough, this use case is trivially easy to handle here, all we
need to do is remove existing activities first, then add the new one.
This will also briefly put it on all activities, but adding new
activities works (and puts it only on that activity), it's only
removing them that fails.
FIXED-IN: 6.4.0


(cherry picked from commit 99f9dc95226719c2be53fd86a4a0a3bae88d0aa2)

Co-authored-by: Christoph Wolk <cwo.kde@posteo.net>

M  +5    -5    libtaskmanager/waylandtasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/e2ae8f54b0390b869770f59c257d45df99b24678