I have a similar odd mouse button all the sudden with 5.14.4

Sometimes mouse click is completely unresponsive. Then the mouse changes from pointer to resize when over the application taskbar. On KDE Neon with 5.14.4 and KF5 5.54.0

Ok it's drag icon, so exact same issue. This is on a light load system, nothing intensive going on.

See also Bug 390034.

I had a feeling the fix there wouldn't be enough and we would still get bug reports. Even though it's good that the dragged icons can't destructively paste desktop files into web browsers anymore, it still appears that our users consider the fact that they're draggable at all to be unexpected.

Conceptually, it makes sense to drag an app icon from the Applications tab, since that's seen as the concept of an app (the class, so to speak). But dragging Task Manager buttons makes less sense because in the UI they represent open *instances* of windows or apps, not the *concept* of the app itself.

Disabling the drag&drop feature completely would indeed eliminate the problem I described. However I believe the bug can be fixed in a conservative way. Please note I clearly had no intention to use drag&drop, and my mouse is good enough to not generate accidental movements/jiggle.

> But dragging Task Manager buttons makes less sense because in the UI they represent open *instances* of windows or apps, not the *concept* of the app itself.

And that's what dragging them is used for by users, too (e.g. to move a window to a different virtual desktop on the pager).

@Alexander 
X or wayland?

There shouldn't be any drag started if we're within the drag threshold.
 
If you can reliably reproduce can you put some console.log() statements inside Task.qml in the task manager applet and see how we end up triggering a drag without moving?

(In reply to Eike Hein from comment #5)
> > But dragging Task Manager buttons makes less sense because in the UI they represent open *instances* of windows or apps, not the *concept* of the app itself.
> 
> And that's what dragging them is used for by users, too (e.g. to move a
> window to a different virtual desktop on the pager).
Wow, I didn't even know you could do that! Perhaps we could only make the Task Manager buttons for open windows draggable within the panel, but not outside of it. And then there's the fact that with an IOTM, dragging an app icon to the pager doesn't make sense since IOTM icons represent apps rather than open windows.

> Wow, I didn't even know you could do that!

I've told you about it a few times during this recurring debate, though ...


>  Perhaps we could only make the Task Manager buttons for open windows draggable within the panel, but not outside of it. 

I recall we've discussed that previously, too: The pager can in theory be on any other panel, or on the desktop, or in a floating window, or it can be some entirely new custom UI using libtaskmanager, or entirely differenty code looking for the same drag MIME type payload.

Good systems are layered properly for interoperability and reuse, you don't bake in assumptions about "there's only one panel ever" :)


> And then there's the fact that with an IOTM, dragging an app icon to the pager doesn't make sense since IOTM icons represent apps rather than open windows.

Both applets show tasks. Some tasks have associated windows, some do not. The only difference is that IOTM groups always, the TM (with default settings) does not. The DND behavior for groups is the same in both applets. If the Present Windows effect is unavailable the IOTM will show the same group popup that the regular TM does and DND from out of the popup works the same way for individual tasks, too.


IMHO there's only one thing to do here: Figure out if there's a bug causing DND to be triggered too easily/erronously (what David is pursuing).

Today the situation described here happened on my system running X11 session, I use the default task manager.

Operating System: Arch Linux 
KDE Plasma Version: 5.15.3
KDE Frameworks Version: 5.56.0
Qt Version: 5.12.2

This is trivially reproducible by clicking and then accidentally dragging. You can end up accidentally re-ordering your icons or creating a panel launcher (Bug 416927).

It's quite easy to do with a touchpad, and also presents an accessibility issue for people with hand tremors, Parkinson's disease, etc. Th compat this, he macOS dock does imposes a minimum threshold before an icon begins to actually get dragged if you click and then immediately drag it a short distance; small drags of some number of pixels get ignored and treated like clicks instead. We might consider doing the same thing here.

> We might consider doing the same thing here.

We do.

Then either the threshold is too small, or it doesn't work. If I click-and-drag an Icons Only Task Manager item, the drag cursor appears after moving the cursor 3 pixels. An appropriate threshold would be more like 10, 15, or 20 pixels.

It is 10 by default.

It can be overriden in kdeglobals [KDE]  StartDragDist

And it used to be configurable from the GUI, see bug 410493.

I found that it was explicitly set to 4 in my kdeglobals file. Some grepping shows that this value is set here: https://cgit.kde.org/plasma-desktop.git/tree/kcms/mouse/backends/x11/evdev_settings.cpp#n82

I do see that plasma-integration uses 10 if it's not set though. But it was.

Maybe we should increase the default to 10 there too? And either way yeah we need to make it user-configurable again.

(In reply to David Edmundson from comment #6)
> @Alexander 
> X or wayland?

X

> There shouldn't be any drag started if we're within the drag threshold.

Right. And even if drag&drop is started, it should terminate at some point after the mouse button is released, however it doesn't happen. I have to click left mouse button again in order to get rid of the dragged item "attached" to the mouse pointer.

> If you can reliably reproduce can you put some console.log() statements
> inside Task.qml in the task manager applet and see how we end up triggering
> a drag without moving?

The problem happens from time to time, but I couldn't find a reliable way to reproduce :(
However AFAIR it happens more often when the OS is constantly swapping.

*** Bug 379900 has been marked as a duplicate of this bug. ***

(In reply to Alexander Potashev from comment #16)

> > If you can reliably reproduce can you put some console.log() statements
> > inside Task.qml in the task manager applet and see how we end up triggering
> > a drag without moving?
> 
> The problem happens from time to time, but I couldn't find a reliable way to
> reproduce :(
> However AFAIR it happens more often when the OS is constantly swapping.

This is what I can easily reproduce on my machine: you click on a task constantly moving your mouse, like in a hurry, and an icon of the task appears near the cursor: drag and drop operation has started, and it continues despite LMB is not hold anymore. After that, one additional click with LMB is needed to get a regular cursor back. I can provide any logs needed if a bit more precise instructions will be provided.
I can live with drag and drop in taskbar but this occasional "cursor jamming" is the thing I wanted to report.

Created attachment 130670 [details]
Edited video with demonstration

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1124

Git commit 7f1c5184d5ad75485504a56bee3bc11a8225bb26 by Nate Graham.
Committed on 06/09/2022 at 19:08.
Pushed by ngraham into branch 'master'.

applets/taskmanager: make it harder to accidentally start a drag

Right now there is code to reduce the liklihood of accidental drags, but
it suffers from two issues that reduce its effectiveness:
- It doesn't internally check for all the parameters used to signify
  that the mouse is pressed, just one which serves as a proxy for the
  rest. As a result, if they get out of sync it's possible for a drag
  to begin even when the mouse isn't pressed.
- It has a distance threshold before starting a drag that defaults to
  10px, but can be overridden in config files to be much less. And 10px
  is quite small anyway.

This commit fixes those issues by checking for all press-based
paremeters when determining whether to start a drag, and and ensuring
that the drag threshold never falls below 1/2 of the icon size no
matter what it's set to in the config file.
FIXED-IN: 5.26

M  +6    -1    applets/taskmanager/package/contents/ui/Task.qml
M  +3    -1    applets/taskmanager/plugin/draghelper.cpp

https://invent.kde.org/plasma/plasma-desktop/commit/7f1c5184d5ad75485504a56bee3bc11a8225bb26

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1217

Git commit e75d90d9074b3bfa90893647ddd3caf31b378876 by Nate Graham, on behalf of Fushan Wen.
Committed on 24/10/2022 at 16:40.
Pushed by ngraham into branch 'master'.

Revert "applets/taskmanager: make it harder to accidentally start a drag"

This reverts commit 7f1c5184d5ad75485504a56bee3bc11a8225bb26.
Related: bug 460809
FIXED-IN: 5.26.2

M  +1    -6    applets/taskmanager/package/contents/ui/Task.qml
M  +1    -3    applets/taskmanager/plugin/draghelper.cpp

https://invent.kde.org/plasma/plasma-desktop/commit/e75d90d9074b3bfa90893647ddd3caf31b378876

Git commit 56e25dafcd235536188ae6969d22ef25400852f0 by Nate Graham, on behalf of Fushan Wen.
Committed on 24/10/2022 at 16:43.
Pushed by ngraham into branch 'Plasma/5.26'.

Revert "applets/taskmanager: make it harder to accidentally start a drag"

This reverts commit 7f1c5184d5ad75485504a56bee3bc11a8225bb26.
Related: bug 460809
FIXED-IN: 5.26.2


(cherry picked from commit e75d90d9074b3bfa90893647ddd3caf31b378876)

M  +1    -6    applets/taskmanager/package/contents/ui/Task.qml
M  +1    -3    applets/taskmanager/plugin/draghelper.cpp

https://invent.kde.org/plasma/plasma-desktop/commit/56e25dafcd235536188ae6969d22ef25400852f0

The fix got reverted since it caused a regression (Bug 460809; re-opening.

If the bug only happens when CPU is busy, the drag helper should probably check the timestamp of each event and drop events when the timestamps are not continuous.

need backport: https://github.com/qt/qtdeclarative/commit/61a9612f5b2a7c33e011d75c7977ea92357a0626

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1224

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2290

Git commit 588ddb6a4775bb7c18e03c5a19e1e09361b9f928 by Nate Graham, on behalf of Fushan Wen.
Committed on 02/11/2022 at 15:37.
Pushed by ngraham into branch 'master'.

libtaskmanager: add workaround for QTBUG-71922

Qt Quick Drag will unconditionally convert a QByteArray to QString, so
some bytes may be lost during the conversion. This adds a workaround to
handle string type mime data, so after porting the task manager applet
away from the custom drag handler, drag a window to the pager applet can
still work.

See also: https://bugreports.qt.io/browse/QTBUG-71922

M  +10   -4    libtaskmanager/xwindowtasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/588ddb6a4775bb7c18e03c5a19e1e09361b9f928

Git commit 17eb382aa86107bbc39cb02c708a271f28cb07c3 by Fushan Wen.
Committed on 02/11/2022 at 16:38.
Pushed by fusionfuture into branch 'master'.

applets/taskmanager: port away from custom drag handler

Qt Quick Drag is more reliable compared to the custom drag handler
because Qt Quick Drag will consider some corner conditions, like
cancelling drag when QQuickItem becomes invisible or disabled. Qt Quick
Drag only accepts string data and will unconditionally convert all
mime data in Drag.mimeData to QString, so a workaround is added.

DragHelper becomes a QQuickItem because when the current virtual
dekstop changes, the current dragged task can disappear, so the drag
will fail. The helper item is used to store drag data and actually
perform the drag, so drag can still work after the task item disappears.

TapHandler is added to Task item because `DragHandler` will blocck
MouseArea from receiving left click events, but TapHandler can still
work normally.

See also: https://bugreports.qt.io/browse/QTBUG-71922
FIXED-IN: 5.27

M  +48   -40   applets/taskmanager/package/contents/ui/Task.qml
M  +4    -1    applets/taskmanager/package/contents/ui/main.qml
M  +21   -61   applets/taskmanager/plugin/draghelper.cpp
M  +5    -22   applets/taskmanager/plugin/draghelper.h

https://invent.kde.org/plasma/plasma-desktop/commit/17eb382aa86107bbc39cb02c708a271f28cb07c3

Git commit 218ff83986140c972078689be1b6156fda7b49a2 by Fushan Wen.
Committed on 23/01/2023 at 02:47.
Pushed by fusionfuture into branch 'master'.

plasmoid: port away from custom drag handler
Related: bug 464528

M  +3    -8    plasmoid/package/contents/ui/main.qml
M  +9    -3    plasmoid/package/contents/ui/task/TaskItem.qml
M  +9    -6    plasmoid/package/contents/ui/task/TaskMouseArea.qml

https://invent.kde.org/plasma/latte-dock/commit/218ff83986140c972078689be1b6156fda7b49a2

Does anyone else have this issue? I do on Kubuntu 23.10 kde 5.27.8  qt 5.15.10
It also happens randomly, I wonder if it has to do with the fact that when you move your mouse from a snap app to your desktop that the cursor changing generates an issue(the default cursor from the system changes when hovering a snap application).

Are there any logs I can provide?

SOLVED Installing the flatpak version of firefox solved the issue which was generated by the snap version.