Sortable ui.sender is null in stop

[Justin Levene]

see ​http://jsfiddle.net/39ZvN/6/

When dragged from another list, ui.sender is null in stop.

[tj.vantoll]

Hi jplevene. Thanks for taking the time to contribute to the jQuery UI project!

The test case you provided is using jQuery 1.8.7. Can you please try your example on the latest version to see if the issue still exists. To get you started, use this boilerplate: ​http://jsfiddle.net/ZgAqH/ Open the link and click to "Fork" (in the top menu) to get started.

[Justin Levene]

I have tried it with the latest JQuery and JQuery UI on my PC and still the same error. At the time of writing this, there is a problem with the jfiddle servers, in that it would not load. I will try to do a jfiddle example as asked another time when jfiddle is hopefully working again.

(I need to use jfiddle to get the code I used)

[tj.vantoll]

jsFiddle should be back up.

[Justin Levene]

New jfiddle ​http://jsfiddle.net/jplevene/FEbxQ/2/

Drag and drop from one list to the other

[tj.vantoll]

Per the docs (​http://api.jqueryui.com/sortable/#event-stop) ui.sender is only populated if the item comes from another sortable.

Therefore, in your example if you sort within the same list ui.sender will always be null and that is expected.

If I move a sortable item from #sort1 to #sort2, #sort1's stop event has a null ui.sender. This is expected as well. #sort2's receive event fires and it has a popuplated ui.sender.

#sort2's stop event is not fired when it receives a sortable item and I believe that is expected behavior as well. Therefore I believe everything here is working as intended. scott_gonzalez?

[Scott González]

Yes, that all sounds right. start and stop are paired, so you'd only get a stop event on the sortable that started the sort, which will not have a sender since it is the origin of the sort.

[Justin Levene]

Replying to scott.gonzalez:

Yes, that all sounds right. start and stop are paired, so you'd only get a stop event on the sortable that started the sort, which will not have a sender since it is the origin of the sort.

Then there is another bug as stop is still fired when an item is dropped from another list. This also means that sender will always be null, therefore why have it there anyway?

[tj.vantoll]

Replying to jplevene:

Replying to scott.gonzalez:

Yes, that all sounds right. start and stop are paired, so you'd only get a stop event on the sortable that started the sort, which will not have a sender since it is the origin of the sort.

Then there is another bug as stop is still fired when an item is dropped from another list. This also means that sender will always be null, therefore why have it there anyway?

stop will only be fired if the sorting action originated from that sortable.

But I believe you are correct that ui.sender will always be null in the stop event. I believe it's there for consistency in case you wanted to use the same function to handle multiple sort events.