Created attachment 176384 [details] Visual demonstration of the issue. ### **Summary** Task Manager: Unexpected behavior when moving non-active icons in Wayland session with manual sorting. --- ### **Description** #### Steps to Reproduce 1. Ensure you are using KDE Neon under a Wayland session. 2. Set the Task Manager to manual sorting mode. 3. Open multiple windows of various applications, ensuring they appear as separate icons (disable grouping). 4. Perform the following sequence: - Select an icon representing an inactive application. Drag it to a new position in the task manager and release the mouse button. - Immediately afterward, select a neighboring icon (without activating its associated application) and begin dragging it to a new position. #### Observed Result - While dragging the second icon, before releasing the mouse button: - The icon you are dragging suddenly resets to its original position. - The neighboring icon that your cursor first hovered over becomes "attached to your cursor" and starts moving instead. - This behavior consistently disrupts attempts to rearrange icons unless specific steps are taken to avoid it. For example: - If you have three distinct icons for the same app (not grouped) and drag the third (rightmost) icon to the left in the first position, this initial move succeeds. - However, if you then immediately try to drag the middle icon to a new position, let's say to the right: - The icon you try to move (middle one) resets to its original position. - The third (rightmost) icon unexpectedly becomes the one being moved, even though it wasn’t selected. #### Expected Result - The icon being dragged should remain selected and move to the intended position without interference. - Other icons should not reset or attach themselves to the cursor unexpectedly. #### Workaround - Click the icon first to activate its associated application, then drag it. This extra step prevents the erratic behavior and allows rearrangement. --- ### **Software/OS Versions** - **Operating System:** KDE Neon 6.2 - **KDE Plasma Version:** 6.2.3 - **KDE Frameworks Version:** 6.8.0 - **Qt Version:** 6.8.0 - **Kernel Version:** 6.8.0-49-generic --- ### **Additional Information** - **Environment:** Wayland session. - A detailed discussion and a visual demonstration of the issue (video/gif) are available in this forum thread: https://discuss.kde.org/t/problem-when-moving-not-active-icons-in-task-manager-kde-neon-wayland/26111
*** This bug has been marked as a duplicate of bug 482770 ***
(In reply to Nate Graham from comment #1) > > *** This bug has been marked as a duplicate of bug 482770 *** I just updated to Qt 6.8.1, my KDE Plasma version is 6.2.4 and i still have the bug, btw the bug i reported is not exactly the same as this one so could it be another one?
There were unfortunately multiple issues, and the final one is fixed in Qt 6.8.2.
(In reply to Nate Graham from comment #3) > There were unfortunately multiple issues, and the final one is fixed in Qt > 6.8.2. Hi, Since the last update of KDE Plasma 6.3 with Qt 6.8.2, the problem seems to be fixed a bit, but sometimes it works, sometimes not... - Operating System: KDE Neon 6.2 - KDE Plasma Version: 6.3.0 - KDE Frameworks Version: 6.10.0 - Qt Version: 6.8.2 - Kernel Version: 6.8.0-49-generic (64-bit) - Graphics Platform: Wayland I have multiple monitors!
I suspect you're hitting Bug 491100, which was just fixed in Qt 6.8.3.
(In reply to Nate Graham from comment #5) > I suspect you're hitting Bug 491100, which was just fixed in Qt 6.8.3. I looked into it and tried installing the patch mentioned here: (In reply to pallaswept from comment #10) > (In reply to Nate Graham from comment #9) > > It's actually https://codereview.qt-project.org/c/qt/qtwayland/+/581714 > > Thanks Nate! > > Works great here, can confirm that patch resolves this issue at my machine. > > I'd normally like to help out my distro by packaging a cherry-picked patch > like this, but it seems like it might be too soon for me to go ahead yet(?). > I'll keep an eye on that link for when it is approved at that end, but if > you feel like it's safe to go ahead and patch distro packages, let me know. > > Thanks again and have a good weekend :) and (In reply to David Redondo from comment #30) > This commit fixes it fully for me > https://codereview.qt-project.org/c/qt/qtwayland/+/623667 Unfortunately, the patch didn't fix my issue. Also, my problem is a bit different from the one described in this bug report. It's more like this: When I sort the icons on one of the taskbars on any monitor (which now works since the last update), and then immediately try to sort icons on a taskbar on another monitor, if I didn’t click on an icon beforehand, it behaves similarly to what I originally described (and shown in the attached video). Additionally, the issue seems somewhat random, sometimes it works with no problems, and other times it doesn’t work at all.
Confirming this bug on Plasma 6.3.1.1., latest Arch, wayland, using Icons-and-Text Task Manager
Created attachment 178723 [details] Bug on Icon-and-Text Task manager on Plasma 6.3.1.1
If you drag something and then immediately click, is everything fine? If yes, then it sounds exactly like Bug 491100. In that case, the options are: 1. The patch doesn't actually fix it 2. You didn't apply the patch correctly
I am afraid I don't understand. What do you mean by "drag something and then immediately click"? Order of tasks get incorrect while I am dragging (while mouse button is still pressed), when I release the mouse button, the order stays incorrect, why would clicking (on what? task that was dragged?) changed anything at that point? Let me attach another demonstration - keep looking on firefox task YouTube, how it "jumps" while I drag another task. Also, I have not patched anything myself, using unmodified plasma from arch repository. And nothing becomes unresponsive (as bug 491100 suggests), everything is responsive, tasks just "jump around" like shown, when manually reordered.
Created attachment 178935 [details] Another showcase of broken manual reordering of task on 6.3.1.1
(In reply to Nate Graham from comment #9) > If you drag something and then immediately click, is everything fine? > > If yes, then it sounds exactly like Bug 491100. In that case, the options > are: > 1. The patch doesn't actually fix it > 2. You didn't apply the patch correctly "immediately click" where/how? On the icon itself that I'm moving? Could you be more precise please, so I try to reproduce? And regarding "2. You didn't apply the patch correctly"? What do you mean by that? I'm almost sure I applied it correctly, but the system told me I already had the patch, so I un-applied and re-applied it. Do you have any guide or advice to apply it properly or to check that it's fully applied?
(In reply to Roman from comment #10) > I am afraid I don't understand. What do you mean by "drag something and then > immediately click"? Order of tasks get incorrect while I am dragging (while > mouse button is still pressed), when I release the mouse button, the order > stays incorrect, why would clicking (on what? task that was dragged?) > changed anything at that point? > > Let me attach another demonstration - keep looking on firefox task YouTube, > how it "jumps" while I drag another task. > > Also, I have not patched anything myself, using unmodified plasma from arch > repository. And nothing becomes unresponsive (as bug 491100 suggests), > everything is responsive, tasks just "jump around" like shown, when manually > reordered. I have exactly the same issue, I can't be more precise than what you said and what i already said!
I'm preeeeeetty your your screen recording shows what I was expecting it show. So let me be more precise with the instructions: 1. Click somewhere on the desktop 2. Click on something in the Task Manager and drag it elsewhere by releasing the mouse button. 3. Before doing anything else, click again. Just click on the thing you just dragged. One left click. 4. Now, try to drag something else. At step 4, does the ordering get messed up, or does it work as expected?
(In reply to Nate Graham from comment #14) > I'm preeeeeetty your your screen recording shows what I was expecting it > show. So let me be more precise with the instructions: > > 1. Click somewhere on the desktop > 2. Click on something in the Task Manager and drag it elsewhere by releasing > the mouse button. > 3. Before doing anything else, click again. Just click on the thing you just > dragged. One left click. > 4. Now, try to drag something else. > > At step 4, does the ordering get messed up, or does it work as expected? Just tried this, and you are right, it works - if I always click on thing I just finished dragging, things don't jump around anymore.
I had a feeling. :) That means it's exactly the same issue as Bug 491100, which means either the fix didn't really fix it, or else you don't actually have the fix. Either way, marking as a duplicate of Bug 491100, and let's continue the discussion in there. *** This bug has been marked as a duplicate of bug 491100 ***
(In reply to Nate Graham from comment #14) > I'm preeeeeetty your your screen recording shows what I was expecting it > show. So let me be more precise with the instructions: > > 1. Click somewhere on the desktop > 2. Click on something in the Task Manager and drag it elsewhere by releasing > the mouse button. > 3. Before doing anything else, click again. Just click on the thing you just > dragged. One left click. > 4. Now, try to drag something else. > > At step 4, does the ordering get messed up, or does it work as expected? Thanks for the clarification. Yes it works "as expected" if I follow these steps, the additional click to "debug" after the dragging operation is what I described in the "Workaround" part of this request's description! But if I don't do it, it does not works, so I don't know if it's already fixed/patched in Upstream, but it don't works in Qt 6.8.2. Can you tell me if it's fixed in Qt 6.8.3?
Yes, it's supposed to be fixed in Qt 6.8.3.
(In reply to Nate Graham from comment #18) > Yes, it's supposed to be fixed in Qt 6.8.3. Thx!