Behavior changed when drag'n'dropping from a BListView

[humdinger]

This is hrev57849, 64bit.

I saw the issue recently with Clipdinger, when dragging a clip from the history (left) to the favorites (right). It used to work, so this appears to be a regression:

The selection of the source (history) changes when the item is dropped in the destination (favorites). When the drag message is processed, CurrentSelection() therefore points to the wrong item.

As I don't want to submit anyone to going through Clipdinger code, attached is a movie clip of the Devices app showing this behaviour. Though in case of Devices, it doesn't harm, because it doesn't actually allow d'n'd.
In the clip, I click and hold an item on the left, and move up and down (the selection moves with it: OK). Then move the mouse to the right (the selection doesn't change any more then the mouse pointer leaves the BListView: OK), I move the mouse down and release the button: Now the selection of the BListView on the left jumps to the position of my mouse: not OK IMO.

While I can try wrangling Clipdinger's code to work again, I think this changed behaviour is wrong and should be fixed. A selection in BListView A should not change when drag'n'dropping an item from it to BListView B.

[humdinger]

D'n'd Devices

[waddlesplash]

Was the problem introduced by hrev57966? Or does it predate that?

[humdinger]

This is hrev57849, 64bit.

[waddlesplash]

Ah, missed that. Well, BListView hasn't changed since last December until just this month...

[jscipione]

Issue addressed in ​https://review.haiku-os.org/c/haiku/+/8045. Don't alter the selection on mouse up if we've initiated a drag and drop operation like Clipdinger does.

[humdinger]

Thanks for the quick fix, John! Tried and has Clipdinger work again as intended.

I hope the patch makes it into beta5...

[waddlesplash]

Fixed in hrev57985 +beta5.