Drag gesture: Delay setting behavior does not adhere to documentation

[shfrmn]

First of all, big thank you to all contributors of this incredibly high-quality library. Now let the nitpicking games begin!

Describe the bug

According to documentation, if both delay and threshold settings are provided for drag, the gesture should only begin after the delay — regardless of the pointer movement. However, as you can see in the linked sandbox, the gesture gets triggered immediately once the threshold is passed and delay is not considered at all. Screenshots from documentation:

Sandbox or Video

Sandbox link

Possible solutions
I would personally prefer if by default delay was always enforced regardless of the pointer movement, but perhaps I'm not aware of the use case for the current behavior. Alternatively, to make everyone happy, a new boolean option could be introduced so the user can select whether delay should always apply or only when the pointer remains still. In any case, if no changes to the implementation are made, the docs should probably be updated.

Information:

• Use Gesture version: v10.3.0
• Device: MBP 13 Pro 2020 M1
• OS: MacOS
• Browser: Firefox, Safari, probably all other

Checklist:

• I've read the documentation.
• If this is an issue with drag, I've tried setting touch-action: none to the draggable element.

[dbismut]

Hi @shfrmn, thanks for the kind words.

Not sure I agree there: there's no real usecase (for me) to force the drag to happen only after xx seconds no matter the intent of the user. Maybe you could elaborate your need?

Delay is here to help with a "click & hold to drag" scenario.

[shfrmn]

Hi @dbismut,

I agree with what you said in the context of desktop use, when the user is moving the mouse while pressing the left button it indeed means they are intending to drag the element. On the other hand on mobile enforcing delay would make it much easier to differentiate between swipe/scroll and drag. The UX of having to hold (as in long tap) the element for some time before it becomes draggable is pleasant and familiar to everyone (think iOS desktop icons).

I did not realize it was an enhancement because it's just one of those things I intuitively expected to work out of the box as an average library user, especially after seeing there's a delay option. It's a bit surprising no one else brought it up before.

No doubt, the behavior I'm talking about is already quite easy to implement in the userland, whether it should be a part of this library or not is not my call. However I'd be happy to help with implementation if it's deemed feasible.

[shfrmn]

P.S. I realized the way I opened the issue was probably confusing since I indicated MacOS as the environment. The main value of hard delay would actually be on mobile when there are two gestures registered in the same area. Since smartphone screen is small, the wider swiping gesture might sloppily start on top of a draggable element and having a hard delay would prevent the drag gesture from triggering completely. Hope the use case makes more sense now.

[dbismut]

Actually no, what you're describing is not trivial to implement in user land (ie distinguishing between a vertical drag and a vertical scroll). But in that case I suggest you use https://use-gesture.netlify.app/docs/options/#preventscrollaxis which is made for this.