Closed Bug 787944 Opened 9 years ago Closed 6 years ago

jQuery UI Sortable triggers a Click in Firefox 15

Categories

(Firefox :: Untriaged, defect)

15 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: richard.webster, Assigned: roc)

References

Details

(Keywords: regression, testcase)

Attachments

(5 files)

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDR; BRI/2; .NET4.0C; .NET4.0E)

Steps to reproduce:

I first logged this issue at http://forum.jquery.com/topic/jquery-ui-sortable-triggers-a-click-in-firefox-15 but they told me it was a bug in FF and to log it here.  For details of my code please see this link.

The problem has only started happening since I upgraded to FF15 last week.

I have a ul (unordered list) element whose li (list items) elements have two events bound to them:
- the jQuery .click event, which shows an alert
- the jQuery UI .sortable event, which repositions (sorts) the list item to a new position in the list that you drag it to 

What I do is drag a list item to elsewhere in the list.


Actual results:

What happens is the item is successfully repositioned in the list AND the click event alert occurs.


Expected results:

What should happen is the item is successfully repositioned in the list (which it is), but NO click event alert occurs.

It works perfectly in IE9, and worked in FF14.  But not in FF15.
Thanks for the report. Could you attach a minimal testcase with your JS script, please.
Attached file HTML source
HTML source
Attached image Initial view
Initial view
Thanks for the fast reply.

I have attached the source (you will need to have the jQuery files in the appropriate folders) and the inital view you should see on loading the page.

Then please try dragging an item as described.

If you need anything else let me know.
Mozregression range:

m-c
good=2012-05-30
bad=2012-05-31
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=65fa5cb6f79c&tochange=3aa566994890

m-i
good=2012-05-29
bad=2012-05-30
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ce3d4fd7033b&tochange=8f8639307984

Bisection needed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file standalone testcase
Ideally a reduced testcase would not contain all of jquery :-). Here's at least a standalone testcase but I haven't reduced away all the jquery inside it yet.
Attached file simple testcase
I'm pretty sure the problem is that if you remove and re-add an element to the DOM between mousedown and mouseup on the element, Gecko can still fire a click event but other browsers never do. This testcase illustrates the situation.

If you trigger a CSS 'display' change on the element (which internally is fairly similar, in Gecko anyway), IE9 and Webkit can fire the click (although Opera does not).
Assignee: nobody → roc
Olli, what do you think the correct behavior should be for the testcase in comment #9?

I think the current Gecko behavior is quite good, and seems to follow the spirit of
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-click
but it's probably easier to align with the other browsers than to get them (and Web content) to change, given other browsers interoperably prevent click events when the element has been removed and readded. Olli, do you agree?
Thanks for the investigation so far.  Is there any update please?
Same issue affects Firefox 21.0 and 22.0 on Mac OS X
Still around in 33.0...
Hello All,

did the below comment solve this issue?

(In reply to Leo Caseiro from comment #14)
> Add the helper clone fix the problem:
> 
> http://api.jqueryui.com/sortable/#option-helper
> 
> I found the answer here:
> https://forum.jquery.com/topic/jquery-ui-sortable-triggers-a-click-in-
> firefox-15
Flags: needinfo?(richard.webster)
Closing this bug due to lack of response.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(richard.webster)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.