input[type=range] does not update ngModel through keyboard input (Chrome/Safari)

[shyndman]

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.

[caitp]

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.

[shyndman]

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]

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.

[shyndman]

@caitp, it's clearly bound to something. I appreciate the input, but please check the Fiddle.

[caitp]

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]

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.

Anybody have an opinion on that?

[shyndman]

#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.