#9990 closed bug (fixed)

Opened April 22, 2014 03:15PM UTC

Closed October 27, 2015 01:39PM UTC

Last modified July 05, 2016 01:53PM UTC

Button: Minor mouse movements cause state inconsistencies in Firefox

Reported by: HikingMike Owned by: HikingMike
Priority: minor Milestone: 1.12.0
Component: ui.button Version: 1.10.4
Keywords: Cc:
Blocked by: Blocking:
Description

This is related to #7665. In that bug, the radio buttons were ignoring mouseclicks if the mouse moved slightly during the click. That's fixed now and the button selects, but the click function does not fire under the same circumstances and it should fire for the same reasons.

I'm personally using several radio button sets in a dialog, and a click to a radio in the final set leads to a save and close of the dialog. This issue makes it more difficult to save/close and also leads to oddly having the clicked radio selected, but not saving/closing.

JSFiddle- http://jsfiddle.net/tLK4K/

Attachments (0)
Change History (11)

Changed April 22, 2014 03:19PM UTC by HikingMike comment:1

Shoot, JSFiddle link should be http://jsfiddle.net/tLK4K/1/

Changed April 22, 2014 09:17PM UTC by tj.vantoll comment:2

owner: → HikingMike
status: new → pending

Thanks for creating this, but I'm actually having trouble recreating it. What browser and OS are you using?

Changed April 22, 2014 11:52PM UTC by HikingMike comment:3

status: pending → new

Windows 7 x64 and Firefox something relatively new. I'll test other browsers soon.

Changed April 23, 2014 05:08AM UTC by HikingMike comment:4

I tested in Firefox v28 (and Win7 x64) and this exhibits the bad behavior I described in the bug.

I tested in Chrome v34 (and Win7 x64) and it does not do the bad behavior! The click event fires the same as the button being selected even when dragging a little.

I tested in IE v11 (and Win7 x64) and the radio buttons just show as regular radio buttons in my JSFiddle demo...not sure what's going on there. Oh, if I change jQuery in the JSFiddle to 1.x (edge) like you had then the buttons show up fine. With the radio buttons showing correctly, it also doesn't do the bad behavior.

Soooo, it's just Firefox for me. Interesting.

Changed April 23, 2014 12:36PM UTC by tj.vantoll comment:5

status: new → open
summary: Button: Radio button & checkboxes do not fire click function if have minor mouse movements → Button: Minor mouse movements cause state inconsistencies in Firefox

Thanks. Here's the same example without the button widget: http://jsfiddle.net/ytUsj/. If you move your mouse when clicking a label, most browsers still "click" the label's radio button, but Firefox does not.

The bigger problem is that not only are events not fired, the state of the underlying controls is off. The fix for #7665 caused a #6970 to regress. We should probably revert https://github.com/jquery/jquery-ui/commit/52e0f768f528e5265b6d7b4afae036b1ff248956, but I'm also curious how the button widget rewrite handles this.

Changed April 23, 2014 05:00PM UTC by HikingMike comment:6

Hey good to hear you discovered more about it. Thanks and good luck to the devs. I'd definitely love to have the buttons working visually and for events with the small mouse movements tolerated as usual.

Changed August 25, 2014 11:27AM UTC by apeterson comment:7

I've got this happening as well - Chrome, IE, Safari, Opera all register radio button clicks, but Firefox misses them sometimes.

This is especially problematic, because to the user, it appears that the button was selected (it displays as selected), and so it is difficult for them to know where the problem is.

As a fallback, it'd be really nice if the button doesn't appear to be selected if it is not.

Changed August 25, 2014 10:18PM UTC by arschmitz comment:8

This is fixed in the button re-write in the re-write I don't handle the click event but rather the change event.

Changed May 12, 2015 11:42AM UTC by scottgonzalez comment:9

#12554 is a duplicate of this ticket.

Changed October 27, 2015 01:39PM UTC by scottgonzalez comment:10

milestone: none → 1.12.0
resolution: → fixed
status: open → closed

Confirmed fixed in master.

Changed July 05, 2016 01:53PM UTC by scottgonzalez comment:11

#14996 is a duplicate of this ticket.