Search and Top Navigation
#6970 closed bug (fixed)
Opened February 11, 2011 05:25AM UTC
Closed May 13, 2011 07:28PM UTC
Last modified February 13, 2012 07:44PM UTC
Button state inconsistencies after (accidental) drag-clicking the button
| Reported by: | muley | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.8.14 |
| Component: | ui.button | Version: | 1.8.9 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
- EXAMPLE -
- THE ISSUE -
If you drag-click on a button, the button's state gets updated, but the underlying input element doesn't get updated. Try this (slow or fast):
1. Mousedown on the button and hold
2. Drag on the button a little
3. Release the mouse button
The UI of the button gets updated, but no events get fired (i.e. input change events, click events, etc.), and the underlying input element doesn't get updated with the new value.
- WHAT'S THE BIG DEAL -
This is a problem because someone may think they've clicked a button (since the button state is updated), but any data sent to the server will not have their clicked value.
- BROWSERS -
After further testing, this is a problem in Firefox, but NOT a problem in IE or Chrome :S
Thanks!
Attachments (0)
Change History (10)
Changed March 28, 2011 09:26PM UTC by comment:1
| status: | new → open |
|---|
Changed May 04, 2011 05:24PM UTC by comment:2
This is fixed in this pull request:
https://github.com/jquery/jquery-ui/pull/198
specifically this commit:
https://github.com/eikes/jquery-ui/commit/16ecdccc4bd59e7f03b8fc033eb3b9f1130aad2c
self.refresh() already does everything :)
Changed May 04, 2011 08:02PM UTC by comment:3
BTW: The behavior is / was caused by different browser behavior when text was selected or mousedrag was done on the label, webkit still sees this as a click, while gecko doesn't
Changed May 13, 2011 07:28PM UTC by comment:4
| resolution: | → fixed |
|---|---|
| status: | open → closed |
Button: Don't fire click/change events if mouse was dragged during click of toggle (checkbox/radio) button. Fixed #6970 - Button state inconsistencies after (accidental) drag-clicking the button.
Changeset: a69a1788bc5cd67c6e627e519e20897a0c238945
Changed May 13, 2011 07:29PM UTC by comment:5
Button: Don't fire click/change events if mouse was dragged during click of toggle (checkbox/radio) button. Fixed #6970 - Button state inconsistencies after (accidental) drag-clicking the button.
(cherry picked from commit a69a1788bc5cd67c6e627e519e20897a0c238945)
Changeset: 427f3d4345c6c3507fefcd9319adaf5588faaad4
Changed May 13, 2011 07:29PM UTC by comment:6
| milestone: | 1.9 → 1.8.14 |
|---|
Changed September 01, 2011 09:14PM UTC by comment:7
| _comment0: | I'm currently experience something very similar to this issue with Firefox 6.0.1. In short, the visual cues of a jQuery("input[type=checkbox]").button() don't stay properly synced up with the checkbox state. In particular, double-clicking on the button seems to desynchronize it. \ \ Testing with jQuery 1.6.2 and jQuery UI 1.8.16. Chrome seems to work fine. \ \ Example: \ \ http://jsbin.com/agupeq → 1314911807803705 |
|---|
I'm currently experience something very similar to this issue with Firefox 6.0.1. In short, the visual cues of a jQuery("input[type=checkbox]").button() don't stay properly synced up with the checkbox state. In particular, double-clicking on the button seems to desynchronize it.
Testing with jQuery 1.6.2 and jQuery UI 1.8.16. Chrome seems to work fine.
Example:
Changed October 06, 2011 03:36PM UTC by comment:8
| _comment0: | This fix breaks drag tolerance on all checkboxes and radiobuttons on all browsers. All OS's that i know of have built in tolerance of dragging a fix pixels, but still fires as a click event. That behaviour is broken by this change. Is a major usability issue for me to have to keep the mouse perfectly still when clicking such a button, when every other normal UI component allows up to 4 pixels of movement. → 1317915449812930 |
|---|
This fix breaks drag tolerance on all checkboxes and radiobuttons on all browsers. All OS's that i know of have built in tolerance of dragging a few pixels, but still registers as a click event. That behaviour is broken by this change. It's a major usability issue for me to have to keep the mouse perfectly still when clicking such a button, when every other normal UI component allows up to 4 pixels of movement.
Changed October 06, 2011 04:07PM UTC by comment:9
@larsch Please file a separate ticket for that. Thanks.
Changed February 13, 2012 07:44PM UTC by comment:10
| _comment0: | This bug isn't fixed. Reproduceable in Firefox Nightly (13.0a1) and Opera 11.61. In IE it works fine. → 1329162353584732 |
|---|
This bug isn't fixed (for buttonsets). Reproduceable in Firefox Nightly (13.0a1) and Opera 11.61. In IE it works fine.
I can confirm the issue with 1.8.11 on firefox, and that it doesn't happen on chromium.