Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
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

Closed

Description

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

Activity

  1. caitp commented on Oct 21, 2013

    @caitp
    Contributor

    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.

  2. shyndman commented on Oct 21, 2013

    @shyndman
    Author

    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/

  3. shyndman commented on Oct 21, 2013

    @shyndman
    Author

    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.

  4. shyndman commented on Oct 21, 2013

    @shyndman
    Author

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

  5. caitp commented on Oct 21, 2013

    @caitp
    Contributor

    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

  6. shyndman commented on Oct 21, 2013

    @shyndman
    Author

    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?

  7. shyndman commented on Oct 21, 2013

    @shyndman
    Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions