Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

input type=range onChange should fire when changing the value using the keyboard arrow keys #554

Closed
subtleGradient opened this issue Nov 17, 2013 · 33 comments · Fixed by #5746

Comments

@subtleGradient
Copy link
Contributor

No description provided.

@sophiebits
Copy link
Collaborator

Chrome doesn't fire the input event when a range is modified using arrow keys, but Firefox does.

@jessep
Copy link

jessep commented Jan 15, 2014

Chrome fires a 'change' event when you change it with keyboard. Possible to use 'change' instead of input?

@sophiebits
Copy link
Collaborator

In Chrome beta and Firefox, 'change' doesn't fire when dragging until mouseup so we should listen to input here too.

@eddhannay
Copy link

I made a JSFiddle to test this: http://jsfiddle.net/vqnMU/embedded/result/

React seems to be listening for input, and triggering input & change whenever it occurs.

Focusing the slider and pressing right:

Browser Event React Event
Chrome 34.0.1847.131** Change -
Safari 7.0.3 Change -
Chrome Canary Input, Change Input, Change
Firefox 29* Input Input, Change
IE 10 Change -

* Firefox triggers change on blur

Additionally for dragging:

Browser Event React Event
Chrome 34.0.1847.131 Input* Input, Change
Safari 7.0.3 Input, Change Input, Change
Chrome Canary Input* Input, Change
Firefox 29 Input* Input, Change
IE 10 Change -

* These browsers all trigger change on drag end

Editing ChangeEventPlugin to listen for change events on all input types (35e7aa4) appears to fix React's change & input event handling for all of the above browsers. Should I make a pull request, or is there a reason that the plugin was only listening for change events on file inputs that I'm missing?

@locks
Copy link

locks commented May 18, 2014

I just ran into this problem when trying to port a widget I have to React.
Can someone in the core give some feedback on whether @eddhannay's suggestion would/wouldn't work? Thanks :)

@syranide
Copy link
Contributor

@locks I would recommend implementing your own, it seems like all the HTML input elements come with a bunch of inconsistencies that can be hard to normalize and are basically unstyle:able.

@sophiebits
Copy link
Collaborator

@syranide I think we should attempt to support all the built-in inputs at least mostly-reasonably.

@syranide
Copy link
Contributor

@spicyj Certainly! But there are lots of weird things that we can't fix... like not being able to read the value of type="number" if it isn't strictly numeric, etc.

@dmmalam
Copy link

dmmalam commented Jan 29, 2015

+1

Any workaround for IE10+ to get react to fire a synth onChange, on a browser onchange for range inputs

@chooven
Copy link

chooven commented Feb 11, 2015

+1 for input on IE10+ firing onChange

@kwhitaker
Copy link

+1 to all the +1

@luisrudge
Copy link

any news? range input is still broken in IE 11.
Works great on Edge, though.

@rippo
Copy link

rippo commented Jun 25, 2015

+1 for this to be applied. Doesn't work for me even on Edge

@genert
Copy link

genert commented Aug 27, 2015

Does not work in IE 11.

@JeanCarriere
Copy link

+1

@bsudekum
Copy link

For what it's worth, I created a work around component while this is worked out in core: https://github.com/mapbox/react-range

@dancoates
Copy link

+1, Love the work that everyone is doing on react, but I do feel like this bug should be a higher priority to fix seeing as we are approaching the 2 year mark from its discovery.

@sophiebits
Copy link
Collaborator

@dancoates I'm sorry that this is a lower priority for us than for you. Feel free to send a pull request though! ChangeEventPlugin is a little hairy but my blog post at http://benalpert.com/2013/06/18/a-near-perfect-oninput-shim-for-ie-8-and-9.html should give you an idea of the general strategy. For range elements, we should listen to both input and change events and fire events when either happens (but only once even if both happen).

@dancoates
Copy link

No need to be sorry, I realise it is a tricky one. I'll take a look at ChangeEventPlugin and see if I can help.
Perhaps a caveats section in the docs would help folks wondering why changes aren't firing? Though I guess this thread is easy enough to find.

@raphaelparent
Copy link

👍 would love to see this fixed!

How I dealt with the problem for now
For my use, I simply added the same event on a onMouseUp event and it works for all IE 10 and above and Edge.

It doesn't give the exact same result because the value is only changed on the mouseup event but I think (for my case anyway) that it degrades beautifully.

@zanarmstrong
Copy link

I also ran into this & would love to see it fixed.

Thanks for the suggestions for workarounds. Adding an "onClick" or "onMouseup" event was very helpful, but it's still suboptimal that nothing happens until the user let's go of the slider.

@kevinfrei
Copy link

Check out this on StackOverflow which explains a way to address getting updates while the user is dragging...

jimfb pushed a commit that referenced this issue Apr 15, 2016
* Only fire input value change events when the value changes

fixes #554, fixes #1471, fixes #2185 (still trying to figure out why)

* catch programmatic value changes

* move value tracking to seperate module
@AlexReff
Copy link

Why is this closed? This is still a problem - onChange does not fire at all in IE11 in our testing. Forced to use https://github.com/mapbox/react-range

@jvanderberg
Copy link

We are using 15.3.2, and are experiencing this issue. Looking at the release notes for the three minor releases since then, I don't see that this has been fixed. Why is it closed? Issue #8168 seems to be the tracking case for it, but it seems like this issue has a much more thorough description of the problem.

@gaearon
Copy link
Collaborator

gaearon commented Jan 10, 2017

If you look at the history above, you will see that the issue was closed by #5746.
If you open this PR, you will see that its milestone is set to 16.

So the fix will be in 16, and we can’t put it in 15.x because it introduces a breaking change in behavior.

I don’t know if it’s possible to backport it to 15.x. @jquense and @nhunzaker would likely be able to answer this.

@jquense
Copy link
Contributor

jquense commented Jan 10, 2017

It is possible! There is even a PR :) already #8575

@gaearon
Copy link
Collaborator

gaearon commented Jan 10, 2017

Oh nice. Can you make a list of DOM PRs that are hanging in there awaiting review?
Then add them to umbrella in #8583 so that the relevant cases have manual tests.

@aweary
Copy link
Contributor

aweary commented Jan 10, 2017

#8575 is on my todo list. Just need to test some stuff locally and then I think we'll be 👍 to merge. I'll make sure to add some relevant cases to #8583 when I get a chance to review it

@nhunzaker
Copy link
Contributor

Anyone working on a browser test fixture for this? If not, I've got some time to write one up.

@jquense
Copy link
Contributor

jquense commented Jan 21, 2017

I was planning on it but haven had a moment yet. feel free to jump in

@nhunzaker
Copy link
Contributor

No worries. There's plenty of other test cases to write up. I've got a PR out related to #8308. I'll shift gears to that.

@c0debreaker
Copy link

I encountered this issue today on my Windows phone. It does not call the method I specified in onChange. When is the fix going to be applied?

@gaearon
Copy link
Collaborator

gaearon commented Nov 24, 2017

This has been released in 15.6.x.

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

Successfully merging a pull request may close this issue.