Bug 402376 - Click on taskbar item sometimes starts drag&drop
Summary: Click on taskbar item sometimes starts drag&drop
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: 5.14.4
Platform: Fedora RPMs Linux
: HI normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 379900 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-12-20 11:54 UTC by Alexander Potashev
Modified: 2022-09-06 19:12 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.26


Attachments
Edited video with demonstration (309.11 KB, video/webm)
2020-08-05 20:49 UTC, Alexander Shchadilov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Potashev 2018-12-20 11:54:28 UTC
SUMMARY
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.

OBSERVED RESULT
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.

EXPECTED RESULT
Should not start drag&drop.

SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.52.0
Qt Version: 5.11.1

ADDITIONAL INFORMATION
Comment 1 Jasem Mutlaq 2018-12-24 11:59:28 UTC
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
Comment 2 Jasem Mutlaq 2018-12-24 12:01:18 UTC
Ok it's drag icon, so exact same issue. This is on a light load system, nothing intensive going on.
Comment 3 Nate Graham 2018-12-27 00:24:25 UTC
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.
Comment 4 Alexander Potashev 2018-12-27 07:01:21 UTC
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.
Comment 5 Eike Hein 2019-01-02 07:40:37 UTC
> 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).
Comment 6 David Edmundson 2019-01-02 09:51:23 UTC
@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?
Comment 7 Nate Graham 2019-01-02 20:19:15 UTC
(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.
Comment 8 Eike Hein 2019-01-03 04:18:06 UTC
> 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).
Comment 9 Patrick Silva 2019-03-26 22:40:40 UTC
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
Comment 10 Nate Graham 2020-02-20 20:27:49 UTC
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.
Comment 11 David Edmundson 2020-02-26 01:20:02 UTC
> We might consider doing the same thing here.

We do.
Comment 12 Nate Graham 2020-02-26 14:59:25 UTC
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.
Comment 13 David Edmundson 2020-02-26 15:28:35 UTC
It is 10 by default.

It can be overriden in kdeglobals [KDE]  StartDragDist
Comment 14 Christoph Feck 2020-02-26 16:15:24 UTC
And it used to be configurable from the GUI, see bug 410493.
Comment 15 Nate Graham 2020-02-26 17:06:39 UTC
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.
Comment 16 Alexander Potashev 2020-03-08 12:44:31 UTC
(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.
Comment 17 Patrick Silva 2020-06-17 15:55:41 UTC
*** Bug 379900 has been marked as a duplicate of this bug. ***
Comment 18 Alexander Shchadilov 2020-07-25 19:14:42 UTC
(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.
Comment 19 Alexander Shchadilov 2020-08-05 20:49:15 UTC
Created attachment 130670 [details]
Edited video with demonstration
Comment 20 Bug Janitor Service 2022-09-03 22:50:11 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1124
Comment 21 Nate Graham 2022-09-06 19:12:02 UTC
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