We traced an Amarok bug report back to a bug in Qt QAbstractItemView.

The git-current version of Amarok calls 'setMouseTracking( true )' on the playlist QListView. This turns out to break drag-and-drop from the KDE desktop Folder View. When the user releases the mouse button, the expected 'dropEvent()' does not happen, but instead an undesired new drag is started, of an item in the playlist.

The culprit is 'QAbstractItemView::mouseMoveEvent(QMouseEvent event)': that function decides to call 'startDrag()' *during the externally-initiated drag-and-drop operation.

The bug can be fixed as follows: there should be an 'if (event->buttons() == Qt:NoButton)' check at the sart of 'mouseMoveEvent()'; if so, it should reset detection of all "drag-ish" operations (drag-and-drop, in-place edit).

That simple check is enough to fix the bug triggered by Amarok.

However, the whole "drag detection" code seems a little brittle. For example, QAbstractItemView shouldn't even reach 'DraggingState' during an externally-initiated drag-and-drop operation. I suspect that that happens in part because 'd->pressedIndex' is treated as relevant in deciding to enter 'DraggingState' even though it might be from a mouse click that happened hours ago.