Opened 6 years ago

Closed 6 years ago

#10068 closed bug (patcheswelcome)

Sortable's Cancel method cancels last sort even after sort completes

Reported by: alewcock Owned by:
Priority: minor Milestone: none
Component: ui.sortable Version: 1.10.4
Keywords: Cc:
Blocked by: Blocking:

Description

The documentation states that the cancel method:

Cancels a change in the current sortable and reverts it to the state prior to when the current sort was started.

However when used dynamically after a sort has completed, it reverts the last change.

I am trying to use the cancel method to cancel active sorts when an event occurs that has to modify the underlying collection. The point is to asynchronously cancel any active sorts that the user may be performing before modifying the collection so that the collection array can stay in sync with the ui. The cancel method does achieve this, however in the case where there is no active sort being performed by the user, calling the cancel method will actually revert the last completed sort action even if that action has long since completed, basically like an Undo function.

At a minimum, if this is by design, the documentation is very unclear as to this functionality especially with the words "current sort". Does the "current sort" never end and it's context lives on forever?

If it is by design, it would be useful to have another method to stop (or cancel!) the current sort (as in the currently executing active sort being performed by the user). Better yet, change the "cancel" method to do this and only this, and add an "undo" method to revert the last completed change.

This is reproducible on the documentation page's example code.

Change History (1)

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

Resolution: patcheswelcome
Status: newclosed

It seems rare that this would occur (this is confirmed by the lack of complaints in the past several years). The cancel() method is going to be removed during the rewrite because it's terrible UX to cancel a sort in the middle of a user action, and calling event.preventDefaul() inside the start/stop callbacks will do the appropriate thing. As such, we'll accept a patch in the current version, but we're unlikely to change the behavior ourselves.

Note: See TracTickets for help on using tickets.