Search and Top Navigation
#9921 closed bug (notabug)
Opened March 21, 2014 02:51AM UTC
Closed March 21, 2014 12:46PM UTC
Last modified March 21, 2014 04:54PM UTC
Slider handle does not stay synchronized with value when mouse exits
Reported by: | janicki | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.slider | Version: | 1.10.3 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
JSFiddle: http://jsfiddle.net/Uczw5/1/
If you quickly drag the slider handle off the slider, the handle is show at the edge of the slider, but the value returned is *not* a min/max value. When the mouse button is released, the change event is triggered and the slider value is correct per the UI.
This is a problem for apps that update a live UI based on slider position. (The end user will experience a "jump" that is not indicated by the slider... so the app and/or the slider will feel buggy.) The slider's UI and its value must be kept in sync.
Attachments (0)
Change History (6)
Changed March 21, 2014 12:31PM UTC by comment:1
Changed March 21, 2014 12:46PM UTC by comment:2
resolution: | → notabug |
---|---|
status: | new → closed |
You're using the API incorrectly. The slide
event provides the value that is about to occur. At the time the event is fired, the value has not changed because the change can be prevented via the event. Please see http://api.jqueryui.com/slider/#event-slide
Changed March 21, 2014 02:51PM UTC by comment:3
Yes that works. Thanks.
It might be helpful to your users to include a note in the value() method's documentation, noting that it does not return the pending and/or visual state when in a slide/change event handler. (However, the slide event is already clearly documented well enough… My bad for not reading that better.)
For what it's worth, it is still a little confusing that the visual cue (the handle) is allowed to change before the value. Maybe the slide event should be called *before* the handle's pending value is rendered?
FYI, I'm coming from using Java Swing for years. In that API, a shouldChange() listener would be called separately to verify changes, before firing change events. Not saying JQuery should be like Java… just offering a possible alternative that would avoid the confusion that sometimes ui.value != value(). Or maybe ui.value could be better named ui.pendingValue?
Just minor feedback… Thanks for a great product.
Changed March 21, 2014 03:04PM UTC by comment:4
For what it's worth, it is still a little confusing that the visual cue (the handle) is allowed to change before the value.
It's not. You're just confused about what's happening because the test case doesn't do what you think it does.
Maybe the slide event should be called *before* the handle's pending value is rendered?
It is.
In that API, a shouldChange() listener would be called separately to verify changes, before firing change events.
That's exactly what the slide
event is. There's just no event that occurs after the value actually changes, while the value is still sliding.
just offering a possible alternative that would avoid the confusion that sometimes ui.value != value()
ui.value
is always different than value()
inside the slide
event.
Changed March 21, 2014 04:45PM UTC by comment:5
OK, got it now. Thanks for taking the time to straighten me out.
Changed March 21, 2014 04:54PM UTC by comment:6
No problem. Feel free to send a pull request against https://github.com/jquery/api.jqueryui.com with suggested wording to improve clarity of this. I feel like we get a ticket like this two or three times a year.
I do find it a bit odd that the
events are not triggered for the final value. I'm not sure exactly why that is at the moment, but for your UI you should be able to listen for both the and events, and perform the same logic for each to avoid the jump.