Skip to main content

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 tj.vantoll comment:1

I do find it a bit odd that the

slide
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
slide
and
change
events, and perform the same logic for each to avoid the jump.

Changed March 21, 2014 12:46PM UTC by scottgonzalez comment:2

resolution: → notabug
status: newclosed

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 janicki 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 scottgonzalez 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 janicki comment:5

OK, got it now. Thanks for taking the time to straighten me out.

Changed March 21, 2014 04:54PM UTC by scottgonzalez 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.