Click on taskbar item sometimes starts drag&drop.
STEPS TO REPRODUCE
1. Run memory- and disk-intensive applications to make sure the system is constantly swapping.
2. Click (and immediately release left button) on an item in Taskbar plasmoid.
3. Move mouse cursor around.
After some time, an application icon is added to the mouse cursor like if you started drag&drop. It's unclear how to cancel this drag&drop operation.
Should not start drag&drop.
(available in About System)
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.52.0
Qt Version: 5.11.1
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).
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.
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)
> X or wayland?
> 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.
M +6 -1 applets/taskmanager/package/contents/ui/Task.qml
M +3 -1 applets/taskmanager/plugin/draghelper.cpp