Bug 402376

Summary: Click on taskbar item sometimes starts drag&drop
Product: [Plasma] plasmashell Reporter: Alexander Potashev <aspotashev>
Component: Task Manager and Icons-Only Task ManagerAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: agurenko, alexander.shchadilov, bugseforuns, kde, kubry, mutlaqja, nate, plasma-bugs, qydwhotmail, subdiff
Priority: HI Keywords: usability
Version: 5.14.4   
Target Milestone: 1.0   
Platform: Fedora RPMs   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=390034
https://bugs.kde.org/show_bug.cgi?id=416927
https://bugs.kde.org/show_bug.cgi?id=410493
Latest Commit: Version Fixed In: 5.27
Bug Depends on: 460809    
Bug Blocks:    
Attachments: Edited video with demonstration

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
Comment 22 Bug Janitor Service 2022-10-21 14:34:37 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1217
Comment 23 Nate Graham 2022-10-24 16:43:06 UTC
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
Comment 24 Nate Graham 2022-10-24 16:43:40 UTC
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
Comment 25 Nate Graham 2022-10-24 16:44:15 UTC
The fix got reverted since it caused a regression (Bug 460809; re-opening.
Comment 26 Fushan Wen 2022-10-24 17:02:23 UTC
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.
Comment 28 Bug Janitor Service 2022-10-29 16:24:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1224
Comment 29 Bug Janitor Service 2022-11-01 11:39:11 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2290
Comment 30 Nate Graham 2022-11-02 15:50:42 UTC
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
Comment 31 Fushan Wen 2022-11-02 16:40:06 UTC
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