#10124 closed feature (notabug)

Opened June 23, 2014 09:49AM UTC

Closed June 23, 2014 01:01PM UTC

Last modified June 24, 2014 12:33PM UTC

mouse event fires out of place with mouse delay option (use case: sortable)

Reported by: saeder Owned by:
Priority: minor Milestone: none
Component: ui.mouse Version: 1.10.4
Keywords: Cc:
Blocked by: Blocking:
Description

When specifying the delay option on a sortable, for example with a value of 1000 and clicking and keeping the mouse moving the sorting does not start with the element with currently is below the mouse pointer, with is confusing.

Therefore I changed my copy of ui.mouse:

I added an option proximity (sort of the opposite of the option distance) and added a clearTimeout on this._mouseDelayTimer when the mouse cursor moves out of the proximity.

This way it performs much nicer.

I suggest a new option proximity.

Attachments (0)
Change History (4)

Changed June 23, 2014 01:01PM UTC by scottgonzalez comment:1

resolution: → notabug
status: new → closed

That's actually extremely confusing behavior. You start on an element and that's the element you're interacting with.

Changed June 24, 2014 07:31AM UTC by saeder comment:2

Replying to [comment:1 scott.gonzalez]:

That's actually extremely confusing behavior. You start on an element and that's the element you're interacting with.

Think of mobile, or more generally, touch devices. I'm pretty sure the delay option is needed there. How else would you distinguish between scrolling and dragging and dropping. Certainly I need it now. That's why I fixed the behaviour in my copy of the jQuery Framework.

It is indeed confusing when one moves the cursor around and then an action is performed where the mouse cursor is not.

Changed June 24, 2014 12:03PM UTC by scottgonzalez comment:3

Arbitrary delays don't help the mobile use case. Actual gesture recognition will. You should be using handles to avoid accidental dragging when trying to scroll.

Changed June 24, 2014 12:33PM UTC by saeder comment:4

Replying to [comment:3 scott.gonzalez]:

Arbitrary delays don't help the mobile use case. Actual gesture recognition will. You should be using handles to avoid accidental dragging when trying to scroll.

On mobile devices the screen is limited. Therefore did not want to use drag handles and - even more importantly - I did not want to introduce a different mode of operation.

I have implemented the start event as a longtap. Then the element being dragged becomes transparent and can be moved. It's working rather nice that way. Perhaps you should consider that as a ergonomic and intuitive way of doing drag and drop.

Anyway the delay option is actually there and it does not work as can reasonably be expected.