input type="range" oninput missing, onchange wrong - by Christof7

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 856998 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 4/19/2014 5:23:27 AM
Access Restriction Public

Description

input type="range" should have an event "oninput" which should be triggered on *any* change/slide of the range. In IE (tested in 11) the oninput does not fire at all, instead the "onchange" is triggered the way "oninput" should work. onchange should only be fired once a change of a range is done. At least that what all other browsers do and maybe the spec says. I was unable to find the passage in the specs so it might even be undefined (see also http://stackoverflow.com/questions/18544890/onchange-event-on-input-type-range-is-not-triggering-in-firefox-while-dragging)

For an example see http://jsbin.com/buguyova/7/edit
Sign in to post a comment.
Posted by Microsoft on 1/12/2016 at 11:58 AM
Thank you for the feedback. This issue appears to have been fixed in Microsoft Edge November Update build 10586. We're not presently working on feature bugs in Internet Explorer outside of security-related issues.
Best Regards,
The Microsoft Edge Team
Posted by Microsoft on 4/21/2014 at 6:11 AM
Thank you for the feedback! We will be investigating this issue further.
We have reproduced the fact that IE11 has a different behavior than other browsers.

Best Regards,
The Internet Explorer Team
Posted by Christof7 on 4/20/2014 at 2:03 AM
Don't know about history of range inputs really, it may well be a mess. But it would be good if all browsers would use the same events (and if defined in the spec the better ;).

I only noticed the IE behaviour when looking at an example of a Chrome only article (which is silly in itself) where the author uses oninput onlyso the code simply does not work in IE at all. If he had used onchange as well it would at least have worked (and due to the current IE behaviour even in the same way).
So a different behaviour is problematic not that it is different but that people still code for a single engine only without even testing in others. Mostly these are kind of tutorial pages so probably have a wide reach and people do copy these bad habits. And as IE seems to get more standards compliant with every release (which is great :) this change would make a webdevelopers life even better again.

(I have noticed (maybe subjectively) a rising number of things which are not according to standards in e.g. Chrome (or Safari) which makes it (and not IE) currently my biggest headache in webdev BTW. Not a good development as a lot of developers or at least a lot of turorial/demo writers seem to test in Chrome only)
Posted by Mr Monopoly on 4/19/2014 at 11:39 AM
Well, the W3C example very specifically indicates what you explain. (see example 3 paragraphs down).

http://www.w3.org/TR/html5/forms.html#event-input-input



However, that example is simply inconsistent with everything else they say. I'm sorry to put it this way, but it reads like childishness, making up things as they go along.
If there were some provision to Esc or somehow cancel the slider action, then there would be some means to un- "commit" the slider action.
But there is not. Since there is no means to un- "commit", a reasonable interpretation is that the change (onchange) event should fire along with input (oninput) in pairs.

Both Opera and Safari do exactly that. They fire those two events in pairs. input+change, input+change, input+change...

Anyway. It's clear from that example what W3C now intends.
It would be good if they stated it in the HTML5 Input-Range spec "bookkeeping details", where it is entirely vague.

http://www.w3.org/TR/html5/forms.html#range-state-(type=range)



--- Chrome drags the slider on mouseover. input events only; no onchange event at all.