Search and Top Navigation
#8108 closed bug (fixed)
Opened February 08, 2012 09:30PM UTC
Closed October 11, 2012 07:24PM UTC
Slider: value goes below min in Firefox 10
Reported by: | highvolt | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 1.8.16 |
Component: | ui.slider | Version: | 1.8.16 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
In Firefox version 10, the returned ui.value during the slide event can go below the min value set for the slider.
Link to jsfiddle: http://jsfiddle.net/qfN8E/12/
The issue is not present in Firefox 9. The bug is present in both Linux and Windows builds of Firefox in jQuery ui version 1.8.16. Test case has been demonstrated with jQuery UI 1.8.16 and jquery 1.7.1. Bug does not appear to be present in jQuery 1.5.2 with jQuery UI 1.8.9.
The bug has not been experienced in various versions of IE (7/8/9), Opera (11.61), or Chrome (16.0.912.77 m) on Windows 7.
The issue is present in sliders with no default values overridden ''except'' for the slide: event callback.
To reproduce the bug, slide the slider from left to right back and forth near the left boundary of the slider. The returned value sometimes goes to -1 despite the default range being limited to 0-100.
Attachments (0)
Change History (14)
Changed February 09, 2012 03:54AM UTC by comment:1
Changed February 09, 2012 12:31PM UTC by comment:2
That's strange, I can't reproduce it with the original fiddle (1.8.16) on Firefox 10 for OS X. I even tried resizing the window a few times to see if it was a fractional pixel problem. Are you moving left and right in a single slide or do you need to constantly start new slides to see the problem?
Changed February 09, 2012 07:26PM UTC by comment:3
_comment0: | After trying the jsfiddle in the comments, I also don't encounter the problem in 1.8.17. \ In the jsfiddle using 1.8.16, the issue can be encountered when moving left and right in a single back-and-forth sliding motion (before a mouseup event). \ \ Hopefully it is a regression that does not recur. It is particularly disruptive when using a slider with the step setting defined: The slider's behavior becomes a bit erratic, sliding 2 step values at the leftmost area of the slider. → 1328815661614910 |
---|
After trying the jsfiddle in the comments, I also don't encounter the problem in 1.8.17.
In the jsfiddle using 1.8.16, the issue can be encountered when moving left and right in a single back-and-forth sliding motion (before a mouseup event).
Hopefully it is a regression that does not recur. It is particularly disruptive when using a slider with the step setting defined: The slider's behavior becomes a bit erratic, sliding 2 step values at once at the leftmost area of the slider.
Changed February 09, 2012 07:35PM UTC by comment:4
milestone: | 1.9 → 1.8.17 |
---|---|
resolution: | → fixed |
status: | new → closed |
I guess I'll close this as fixed in 1.8.17. I'm not sure why I still can't reproduce this with 1.8.16.
Changed February 10, 2012 01:49AM UTC by comment:5
For the record I can also easily recreate this on Firefox 10 on Windows with 1.8.16, and can't recreate it with 1.8.17. Window resolution doesn't seem to matter. Weird.
Changed March 01, 2012 12:59PM UTC by comment:7
milestone: | 1.8.17 → 1.9 |
---|---|
resolution: | fixed |
status: | closed → reopened |
summary: | ui.value goes below min slider value when fetched during slide event → Slider: value goes below min in Firefox 10 |
I can now reproduce this. Seeing the same results as posted in #8153.
Changed March 01, 2012 01:00PM UTC by comment:8
priority: | minor → major |
---|---|
status: | reopened → open |
Changed March 01, 2012 05:24PM UTC by comment:9
I can also recreate the issue on the demo page: http://jqueryui.com/demos/slider/range.html. Seems like it's still an issue in master too - http://jsfiddle.net/UATJW/1/.
Changed March 20, 2012 06:00PM UTC by comment:10
Also occurs in Firefox 11, latest patches on Ubuntu 10.04.4. If Firebug is installed (I have 1.9.1 on this system) and Firebug is open, the problem is no longer present. Close Firebug and the problem is back.
Changed March 29, 2012 03:06AM UTC by comment:11
I've been able to limit this down to this block of code in _trimAlignValue of jquery.ui.slider.js:
if ( Math.abs(valModStep) * 2 >= step ) { alignValue += ( valModStep > 0 ) ? step : ( -step ); }
This bug occurs when the valModStep variable is set to a value in between 0.5 and 1.0, therefore it goes into the code block. Since valModStep is > 0 it should add step (i.e. +1 in this example) to alignValue, changing it from 0 to +1. I tested Chrome and when this situation occurs alignValue is indeed set to +1. However, in Firefox alignValue ends up being set to -1 instead of +1 resulting in this bug, I have no idea why.
rmcouat is correct, if you have FireBug open the bug will not occur, which explains a lot of the trouble we were having recreating this earlier. However, I found that having Firefox's built in Web Console open doesn't suppress the bug, so you can use that to throw in some console logging to see the behavior I'm talking about.
Changed March 31, 2012 12:59AM UTC by comment:12
Ok I'm even more confused. I added in the following logging in the _trimAlignValue function in jquery.ui.slider.js
console.log('step', step); console.log('alignValue', alignValue); console.log('valModStep', valModStep); if ( Math.abs(valModStep) * 2 >= step ) { alignValue += ( valModStep > 0 ) ? step : ( -step ); console.log('new alignValue', alignValue); }
When this -1 situation occurs the following gets logged.
step 1
alignValue 0
valModStep 0.6451637514175907
new alignValue -1
I must be missing something because that shouldn't be possible.
Changed October 11, 2012 02:53PM UTC by comment:13
milestone: | 1.9.0 → 1.11.0 |
---|
Changed October 11, 2012 07:24PM UTC by comment:14
milestone: | 1.11.0 → 1.8.16 |
---|---|
resolution: | → fixed |
status: | open → closed |
This seems to have been fixed in Firefox.
I see the issue on Firefox 10 for OS X. I don't have a logical explanation for this, but the issue doesn't seem to be present in 1.8.17 - http://jsfiddle.net/6vNm7/1/. I also can't recreate the issue on the latest from Git.