Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#8842 closed bug (notabug)

Sortable ui.sender is null in stop

Reported by: Justin Levene Owned by: Justin Levene
Priority: minor Milestone: 1.10.0
Component: ui.sortable Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:

Description

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

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

Change History (8)

comment:1 Changed 10 years ago by tj.vantoll

Owner: set to Justin Levene
Status: newpending

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.

comment:2 Changed 10 years ago by Justin Levene

Status: pendingnew

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)

Last edited 10 years ago by Justin Levene (previous) (diff)

comment:3 Changed 10 years ago by tj.vantoll

Status: newpending

jsFiddle should be back up.

comment:4 Changed 10 years ago by Justin Levene

Status: pendingnew

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

Drag and drop from one list to the other

Last edited 10 years ago by Justin Levene (previous) (diff)

comment:5 Changed 10 years ago by 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?

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

Resolution: notabug
Status: newclosed

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.

comment:7 in reply to:  6 ; Changed 10 years ago by 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?

comment:8 in reply to:  7 Changed 10 years ago by 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.

Note: See TracTickets for help on using tickets.