You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
input[type=range] does not update ngModel through keyboard input (Chrome/Safari) #4554
When the input has focus, keyboard controls for changing value (i.e. direction keys, and possibly others) do not update the associated ngModel. Clicks work perfectly.
I'm running against Angular 1.2.0-rc.3. Both Chrome and Safari demonstrate this issue, but Firefox does not.
Firefox most likely doesn't support input[type=range] on desktop browsers (they tend to suck at implementing html5 input types on desktop versions, only in metro/android/b2g versions), so it's probably being treated as input[type=text].
To my knowledge, angular does not implement a directive for input[type=range] to sort of weasel this functionality in, although I'd have to double check. edit yeah, no directive for range inputs.
Hmm, I'm wrong, FF does seem to support input[type=range] without messing in about:config on at least FF23. But as I've said, there's no directive for it, so yeah.
After a bit more digging, it appears that Chrome/Safari range inputs do not fire input events on arrow keys, while the Firefox control does. I suspect this is why Firefox works, while the other two do not.
It's treated as a textInputType, which does binding hackery intended for things reflecting text inputs. It's not really intended for a widget like the range slider, although it theoretically could work in some cases.
Since it's not readily available, perhaps you'd be interested in implementing a directive which portably handles the events emited by range sliders, as well as text inputs when they're used as a fallback
Edit: Sorry, browser explosion before I was finished writing.
I'd have to think about it for a bit.
Building a rangeInputType off of numberInputType to handle keyboard controls would be a good start, but there's one strange detail.
In the case where the browser fires input events (like Firefox does), $setViewValue will be called twice per change -- one time by textInputType (which numberInputType is based on) on the input event, and another time by the "arrow" keyboard handler that rangeInputType will register.
By the looks of it, this isn't a huge issue since $setViewValue doesn't do much when called multiple times with the same arg, but it would be making an assumption that future versions of the code will work the same way.
Just discovered this. Looks as if other issues are holding back a rangeInputType. I'll keep my eyes on open for resolution before moving forward with anything.
Activity
caitp commentedon Oct 21, 2013
Firefox most likely doesn't support
input[type=range]on desktop browsers (they tend to suck at implementing html5 input types on desktop versions, only in metro/android/b2g versions), so it's probably being treated asinput[type=text].To my knowledge, angular does not implement a directive for
input[type=range]to sort of weasel this functionality in, although I'd have to double check. edit yeah, no directive for range inputs.Hmm, I'm wrong, FF does seem to support
input[type=range]without messing inabout:configon at least FF23. But as I've said, there's no directive for it, so yeah.shyndman commentedon Oct 21, 2013
Firefox does support input[type=range], on Mac at least, and Angular handles keyboard input from the Firefox control appropriately.
Safari and Chrome are the problem.
jsfiddle demonstrating the issue: http://jsfiddle.net/84T86/
shyndman commentedon Oct 21, 2013
After a bit more digging, it appears that Chrome/Safari range inputs do not fire
inputevents on arrow keys, while the Firefox control does. I suspect this is why Firefox works, while the other two do not.shyndman commentedon Oct 21, 2013
@caitp, it's clearly bound to something. I appreciate the input, but please check the Fiddle.
caitp commentedon Oct 21, 2013
It's treated as a
textInputType, which does binding hackery intended for things reflecting text inputs. It's not really intended for a widget like the range slider, although it theoretically could work in some cases.Since it's not readily available, perhaps you'd be interested in implementing a directive which portably handles the events emited by range sliders, as well as text inputs when they're used as a fallback
shyndman commentedon Oct 21, 2013
Edit: Sorry, browser explosion before I was finished writing.
I'd have to think about it for a bit.
Building a rangeInputType off of numberInputType to handle keyboard controls would be a good start, but there's one strange detail.
In the case where the browser fires
inputevents (like Firefox does), $setViewValue will be called twice per change -- one time by textInputType (which numberInputType is based on) on the input event, and another time by the "arrow" keyboard handler that rangeInputType will register.By the looks of it, this isn't a huge issue since $setViewValue doesn't do much when called multiple times with the same arg, but it would be making an assumption that future versions of the code will work the same way.
Anybody have an opinion on that?
shyndman commentedon Oct 21, 2013
#2085
Just discovered this. Looks as if other issues are holding back a rangeInputType. I'll keep my eyes on open for resolution before moving forward with anything.