Sortable ui.sender is null in stop

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.

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)

jsFiddle should be back up.

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

Drag and drop from one list to the other

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?

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.

Replying to [comment:6 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?

Replying to [comment:7 jplevene]:

Replying to [comment:6 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.