input type=range onChange should fire when changing the value using the keyboard arrow keys
subtleGradient opened this issue · 33 comments
Chrome doesn't fire the input event when a range is modified using arrow keys, but Firefox does.
Chrome fires a 'change' event when you change it with keyboard. Possible to use 'change' instead of input?
In Chrome beta and Firefox, 'change' doesn't fire when dragging until mouseup so we should listen to input here too.
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?
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 :)
@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.
@syranide I think we should attempt to support all the built-in inputs at least mostly-reasonably.
@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.
+1
Any workaround for IE10+ to get react to fire a synth onChange, on a browser onchange for range inputs
+1 for input on IE10+ firing onChange
+1 to all the +1
any news? range input is still broken in IE 11.
Works great on Edge, though.
+1 for this to be applied. Doesn't work for me even on Edge
Does not work in IE 11.
+1
For what it's worth, I created a work around component while this is worked out in core: https://github.com/mapbox/react-range
+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.
@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).
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.
👍 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.
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.
Check out this on StackOverflow which explains a way to address getting updates while the user is dragging...
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
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.
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.
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.
Anyone working on a browser test fixture for this? If not, I've got some time to write one up.
I was planning on it but haven had a moment yet. feel free to jump in
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.
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?
This has been released in 15.6.x.