Bug 456873 - Unable to use activities since Plasma 5.25.0
Summary: Unable to use activities since Plasma 5.25.0
Status: REOPENED
Alias: None
Product: kwin
Classification: Unclassified
Component: activities (show other bugs)
Version: 5.25.0
Platform: Other Linux
: VHI normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
: 455626 455679 456099 457253 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-07-18 17:34 UTC by wptpqetu
Modified: 2022-08-08 15:30 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wptpqetu 2022-07-18 17:34:19 UTC
Since Plasma 5.25.0 It is impossible to switch between applications, either from the Task Manager or by Alt + Tab, without first making many clicks or showing the desktop. Only the last active application is visible but the entire work area is unusable.
My entire workflow has completely stopped because of this error and I have had to limit myself to using a single activity.


STEPS TO REPRODUCE
1. Open some applications
2. Switch to another activity
3. Back to previous one

OBSERVED RESULT
Active application is not visible and all the desktop is unusable

EXPECTED RESULT
Is possible to switch between applications and activities without annoying behavior. 

SOFTWARE/OS VERSIONS
Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.15.0-41-generic (64-bit)
Graphics Platform: X11
Comment 1 ]\/[ ]\/[ ]_ 1357 2022-07-19 17:59:06 UTC

*** This bug has been marked as a duplicate of bug 455626 ***
Comment 2 David Edmundson 2022-07-27 12:20:56 UTC
Git commit a7520b3659d2364d4c1e10246166243438ba084e by David Edmundson.
Committed on 27/07/2022 at 12:20.
Pushed by davidedmundson into branch 'master'.

Fix activity swtiching through UserActions menu

On wayland the code to keep windows on the current activity whilst the
window was broken was completely broken in porting. We only held the
block for the duration of the method even though the popup remained open
for longer.

On X11, when removing the window from the current activity it would not
update correctly and remain visible. The code path was as follows:
 - the menu is shown an event loop is started
 - we change the activities
- as we close the menu focus changes and workspace calls
UserActionsMenu::close this unsets m_window
- We then never call the blockActivityUpdates(false) at the end of
UserActionsMenu::show

This patch addresses both at once.

We get rid of the nested event loop as that was always evil. This means
slotWindowOperation no longer needs to be queued.

We perform cleanup of m_window and the activity blocker when the menu
closes which should be safer.

M  +15   -11   src/useractions.cpp
M  +8    -0    src/useractions.h

https://invent.kde.org/plasma/kwin/commit/a7520b3659d2364d4c1e10246166243438ba084e
Comment 3 David Edmundson 2022-07-27 12:21:52 UTC
Git commit 7ccc489cb8a74166b06150624fbb9728ab25ea63 by David Edmundson.
Committed on 27/07/2022 at 12:21.
Pushed by davidedmundson into branch 'cherry-pick-a7520b36'.

Fix activity swtiching through UserActions menu

On wayland the code to keep windows on the current activity whilst the
window was broken was completely broken in porting. We only held the
block for the duration of the method even though the popup remained open
for longer.

On X11, when removing the window from the current activity it would not
update correctly and remain visible. The code path was as follows:
 - the menu is shown an event loop is started
 - we change the activities
- as we close the menu focus changes and workspace calls
UserActionsMenu::close this unsets m_window
- We then never call the blockActivityUpdates(false) at the end of
UserActionsMenu::show

This patch addresses both at once.

We get rid of the nested event loop as that was always evil. This means
slotWindowOperation no longer needs to be queued.

We perform cleanup of m_window and the activity blocker when the menu
closes which should be safer.


(cherry picked from commit a7520b3659d2364d4c1e10246166243438ba084e)

M  +15   -11   src/useractions.cpp
M  +8    -0    src/useractions.h

https://invent.kde.org/plasma/kwin/commit/7ccc489cb8a74166b06150624fbb9728ab25ea63
Comment 4 Bug Janitor Service 2022-07-27 12:51:37 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kactivitymanagerd/-/merge_requests/28
Comment 5 Nate Graham 2022-07-27 13:30:30 UTC
*** Bug 456099 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2022-07-27 13:30:33 UTC
*** Bug 455626 has been marked as a duplicate of this bug. ***
Comment 7 David Edmundson 2022-07-27 15:15:21 UTC
*** Bug 455679 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2022-07-29 18:01:50 UTC
*** Bug 457253 has been marked as a duplicate of this bug. ***
Comment 9 Kevin Guertin 2022-08-04 13:38:00 UTC
If this was supposed to have been fixed in 5.25.4, I don't think it has. I have received this update today in KDE Neon, and none of the issues experienced with activities since 5.25.0 (as detailed on this bug and its duplicates) have been addressed. 

Windows management is still broken in X11, which affects not only windows, but all context menus (in all apps, not just Plasma), dialogs, and even the kicker menu. Activating any of these (or switching Windows) still requires me to switch to a different Activity and back again before I can see and interact with the window/menu. This also still causes Latte Dock to crash when logging in to the session when Latte is set to have multiple layouts based on Activities. It takes multiple attempts to load Latte after login before it will load without crashing.
Comment 10 goo 2022-08-04 15:28:11 UTC
How is it possible that this bug is marked FIXED? I still suffer from broken window management even on 5.25.4 since Plasma 5.25.0 on all my machines with multiple monitors running Fedora 36. This is an inacceptable regression that disrupts Plasma Desktop usage.
Have to disable compositing to switch windows.
Comment 11 David Edmundson 2022-08-04 15:57:13 UTC
Git commit 0a7acab2760f85c934dcee1f62e2d66053a3c9f0 by David Edmundson.
Committed on 04/08/2022 at 15:08.
Pushed by davidedmundson into branch 'master'.

Defer session startup until KAMD is up

Otherwise we can session restore occur before kwin has loaded
activities. This means kwin will fail to put windows back on the correct
activity.

Races are avoided because ksmserver will then make a blocking DBus call
to kwin on session restore. DBus guarantees order so it will have also
dispatched the service status to kwin and we know kwin will have handle
that first.

Testing done:
Added "sleep(10)" into the main function. Everything resumed on the
correct activities.

M  +1    -0    src/plasma-kactivitymanagerd.service.in

https://invent.kde.org/plasma/kactivitymanagerd/commit/0a7acab2760f85c934dcee1f62e2d66053a3c9f0
Comment 12 goo 2022-08-05 13:47:12 UTC
(In reply to David Edmundson from comment #11)
> Git commit 0a7acab2760f85c934dcee1f62e2d66053a3c9f0 by David Edmundson.
> Committed on 04/08/2022 at 15:08.
> Pushed by davidedmundson into branch 'master'.
> 
> Defer session startup until KAMD is up
> 
> Otherwise we can session restore occur before kwin has loaded
> activities. This means kwin will fail to put windows back on the correct
> activity.
> 
> Races are avoided because ksmserver will then make a blocking DBus call
> to kwin on session restore. DBus guarantees order so it will have also
> dispatched the service status to kwin and we know kwin will have handle
> that first.
> 
> Testing done:
> Added "sleep(10)" into the main function. Everything resumed on the
> correct activities.
> 
> M  +1    -0    src/plasma-kactivitymanagerd.service.in
> 
> https://invent.kde.org/plasma/kactivitymanagerd/commit/
> 0a7acab2760f85c934dcee1f62e2d66053a3c9f0

Does this mean that this commit fixes #456873 for sure? If this is the case I really hope that distribution mantainers can backport it to 5.25.4, otherwise it means that windows switching will be broken for another month or so, until 5.25.5 release.
Comment 13 goo 2022-08-05 23:51:14 UTC
Please, disregard my previous comments. Due to package conflicts kwin-x11 package was not upgraded to 5.25.4. Had to force it and can now confirm that this bug has been fixed. Sorry for the rant
Comment 14 goo 2022-08-06 00:05:12 UTC
(In reply to goo from comment #13)
> Please, disregard my previous comments. Due to package conflicts kwin-x11
> package was not upgraded to 5.25.4. Had to force it and can now confirm that
> this bug has been fixed. Sorry for the rant

Spoken too soon. After a few more minutes switching windows caused this bug to kick in again. The last used window remain visibile with the focus on the window (hidden) that I switched to. So can confirm that this bug also affects 5.25.4. And yes, I restarted kwin_x11. Have to disable compositing or limit activities to just one.
Comment 15 Gauthier 2022-08-06 17:18:52 UTC
Sadly I can confirm that at least the window/menu/tooltip focus issue does not seem to be fixed in 5.25.4.

When using more than one activities, and after a while working with several windows, some windows remain displayed on top (though not actionable) even if another one should be in focus, context menu (like right click) remain hidden/invisible behind the window. You can see it as even context menu on plasma panels (right click on a panel) appear behind the panel instead of on top.

It "seems like" things starts going wrong especially after using apps like Firefox and LibreOffice (I'm using the repo versions, not snap or flatpak)....but I can't say I'm sure.

Things work perfectly fine if using a single activity. The more activity I use the more things go wrong (with only two activity it seems like switching back and forth between the two resolve the issue but with more than two that does not work)

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.4
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.15.0-43-generic (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620