Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#10124 closed feature (notabug)

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.

Change History (4)

comment:1 Changed 5 years ago by Scott González

Resolution: notabug
Status: newclosed

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

comment:2 in reply to:  1 Changed 5 years ago by saeder

Replying to 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.

comment:3 Changed 5 years ago by Scott González

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.

comment:4 in reply to:  3 Changed 5 years ago by saeder

Replying to 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.

Note: See TracTickets for help on using tickets.