[BUG] [v3] Drag/Drop Actions not working as expected sometimes

[MeestorX]

Is this a bug in companion itself or a module?

• [X] I believe this to be a bug in companion

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

SOMETIMES, an action cannot be drag/dropped to re-order or move the action. I haven't really gotten to the bottom of why some actions will drag/drop while others don't. Sometimes when dragging one action, it drags both too. Also, when dragging from one action type to another (e.g. from press to release), a nice dashed "drop here" target appears. When just re-ordering actions within the same type, there's no "drop here" and the actions flash and jump up and down making it hard to see where the action will land when dropped. As well, I don't think actions can be re-ordered when minimized.

Additionally, I don't see a way to drag/drop an action from one step to another.

Steps To Reproduce

Add some actions and try dragging them around. Sometimes they can be, sometimes not.

Expected Behavior

Dragging always works.

Environment (please complete the following information)

- OS: MacOS Ventura 13.2.1
- Browser: Safari 16.3
- Companion Version: 3.0.0+5673-beta

Additional context

Video of weirdness... https://www.dropbox.com/s/5m04d3teu6v64o4/Drag-Drop%20Weirdness%202023-02-21%20at%2010.21.43%20AM.mov?dl=0

[MeestorX]

Are you able to reproduce this issue, @Julusian ?

[Julusian]

I have seen some weirdness around dragging of actions, and I did start prototyping changing the drag and drop library which appeared to help, but never finished the change

[Julusian]

actions flash and jump up and down making it hard to see where the action will land when dropped.

I'm looking into this now, as I have found a reliable reproduction of this (button has 2 actions/feedbacks which render at different heights), and with some changes I am playing around with this bug makes the dragging really painful.

I think this is simply a problem where once we swap the actions, because the heights are different, the cursor position that triggered the first move, is not over the dragged item (like it would be if heights were the same) and is instead still over the same drop element. So the swap happens again. and repeats until the mouse has moved far enough to not be in this middle grey area.

My current attempt at fixing this is to make it remember what you have dragged over, so that it can reject performing the same swap without a direction change. This isn't perfect (especially with the other changes which prompted looking into this), but is definitely a lot better than before. Instead of firing too often, it is not firing enough, but this can typically be resolved with a bit of a wiggle of the mouse. I also don't have any compensation for bad movements (generally moving upwards, but accidentally moved a pixel downwards), which could negate this fix.

I did start looking into doing something more maths/coordinates heavy, but with the varying heights where the mouse could end up being completely on the other side of drop element (if the drop is collapsed), I feel like this won't be a viable solution.

[istnv]

I've noticed that delay group actions will not drag at all. The short-press group will drag re-order or drop to a delay group, but anything in the delay group will not drag at all.

[Julusian]

@istnv I'm not seeing this.

There are some other quirks, in the actions dragging which could be tackled. But making these perfect is very hard, due to the variable size of everything.

[istnv]

Chrome on Windows 10, Companion 3.4 stable on Linux. The cursor changes to the drag-arrow when hovering. Click seems to work near the bottom of the action 'row'. I can drag single lines from 'short' to 'held'. Dragging from 'held' to 'short' moves all lines.