input[type="range"] "change" event firing differs from native implementations

[hparra]

On recent versions of Webkit and Firefox the change event fires after every step of input[type="range"]. The webshim polyfill change seems to fire on keyup/mouseup.

My original "change" method for input[type="range"] was binded to keyup/mouseup for performance reasons.

From what I've seen in range-ui.js, I assume my listeners stay on the original element and the change event is triggered when the polyfill changes the original's value on each step. Is this correct?

[aFarkas]

Yes, you should bind to the original element.

The change event is triggered if a a) value was changed by the user and b) commit action (mouseup or keyup in case of a range input) or a activation/blur behavior happened. The behavior in FF is correct, while the behavior in Chrome is busted. Actually Chrome-Dev doesn't want to change this.

• http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#event-input-input
• http://code.google.com/p/chromium/issues/detail?id=155747

Is this just a question or do you think there is something wrong with webshims implementation. Please re-open, if there is a bug.

[hparra]

I understand now: webshims implements change and input events correctly, as does FF. Webkit and IE10 trigger change incorrectly, with IE10 not having input at all. Do you know of any low-level (global) jquery fix for this?

Thanks for the library.

[aFarkas]

The input event is already fixed by webshims in IE10/11. I have just added some code to fix the change event in IE10/11, chrome and Safari. The fix is currently turned off by default. You can turn it on by setting the fixRangeChange to true:

webshims.setOptions('forms', {fixRangeChange: true});