cdkDragStartDelay behavior has changed in version 8.1.0

[livthomas]

It seems that the behavior of drag start delay has been changed between Angular CDK versions 8.0.0 and 8.1.0. I think this is a breaking change since it completely changes the way users interact with draggable items. I am not sure if the current behavior is really intended.

Reproduction

8.0.0: https://stackblitz.com/edit/angular-cdkdragstartdelay-80
8.1.0: https://stackblitz.com/edit/angular-cdkdragstartdelay-81

Steps to reproduce:

1. Click on any item.
2. Try to drag it as soon as possible.

Expected Behavior

In the previous version it did not matter if the mouse was clicked or immediately moved. The dragging started anyway after the specified delay.

Actual Behavior

In the current version the item is not being dragged when you move the mouse immediately after the initial click. It only works if you stay at the click position for the specified delay time and then move the mouse.

Environment

• Angular: 8.0.0+
• CDK/Material: 8.1.0+
• Browser(s): Google Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): Fedora Linux 29

[Achilles1515]

Look at the release notes for 8.1.

• drag-drop: fix drag start delay behavior to allow scrolling

[livthomas]

@Achilles1515 Sure, I have seen that. I just wonder if this is the right behavior or if the fix could be implemented some other way.

[andrewseguin]

@crisbeto Can you provide details on the intentions behind the delayed start and whether the change was intended?

[crisbeto]

The change was intentional in #16228. I approved the PR because the change seemed reasonable, but I can see how the old behavior made sense as well.

[amitport]

I think both behaviors should be supported. I have another use-case for the old behavior (the one that only cares about time pressed not about where the mouse is):

Support click/doubleclick action on a draggable item.

If a user's intention is to doubleclick (triggering some automated action) I don't want her to see any movement of the item (which can happen without delay option). If a user wants to drag, she usually just drags away and expect the item to follow (maybe after a short delay, but we do not expect to have to stay on the item)

In any case, @andrewseguin @crisbeto shouldn't this be p2/regression since a valid behavior stopped working?

[zuzhal]

Any news about this? I would also prefer to have a possibility to switch between these 2 behaviors as @livthomas suggested.
Can somebody give me hints on implementing the "old" behavior?