853670 - onchange event on input type=range is handled differently across browsers

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English US, defect)

Description

[Markus Popp]

Filing as separate bug according to suggestion at https://bugzilla.mozilla.org/show_bug.cgi?id=344618#c47

"I just played with <input type="range"> and found differences on how the onchange event is handled across browsers.

While IE10, Chrome and Opera trigger onchange events while the slider is dragged, Firefox only triggers an onchange event when dropping the slider to its new position. Which makes the onchange event rather unusable if the user should see the effect of moving the slider immediately.

It appears as the oninput event comes to the rescue, with that it works fine in Firefox, Opera and Chrome ... but unfortunately IE10 doesn't recognize it at all.

So to have a smooth implementation that works in Firefox, Chrome, Opera and IE10 it requires a mix of both onchange and oninput, which is not ideal of course.

Anything planned to fix this?"

Comment 1

[Frank Yan (:fryn)]

Ours is intended behavior. The spec is ambiguous, because it uses the subjective standard of a user committing to a value as the sole criterion for whether to fire an change event: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#event-input-change

The primary problem with firing onchange events during the drag is that it then is fired just as often as oninput changes, leaving no event to listen to if one simply wants to know when a change has been committed, by a similar standard to how onchange events work with regard text inputs and the keyboard. There are developers that have expressed frustration with the behavior in other browsers: http://stackoverflow.com/questions/5165579/onchange-event-for-html5-range

Comment 2

[Markus Popp]

(In reply to Frank Yan (:fryn) from comment #1)

> The primary problem with firing onchange events during the drag is that it
> then is fired just as often as oninput changes, leaving no event to listen
> to if one simply wants to know when a change has been committed, by a
> similar standard to how onchange events work with regard text inputs and the
> keyboard.

Totally makes sense, and it seems that the best solution would be if Microsoft added support for oninput to IE.

But lets not forget that Chrome and Opera handle onchange like IE10 does (and as far as I have seen identical to oninput), so there is a risk that web devs start implementing onchange while what they actually want (according to the spec) is oninput. Unless a web dev wants to add separate solutions for IE10 and Firefox, they'd have to leave one of both behind, and the winner is not always the one who does it correctly according to the spec.

Comment 3

[Jonathan Watt [:jwatt]]

Yes, this was a deliberate design decision - see the comments in bug 851090. That IE10 does not fire 'input' events (at least not for onchange?), and that other implementations fire 'change' events continuously is unfortunate, but I think we should maintain the behavior that we have. That's more to do with catering for the different needs of different users and being consistent with other input types than purely "because the spec says so". Ultimately this is up to the DOM owners/peers though.

Comment 4

[Markus Popp]

I understand ... it's bad when the one who does it right has to adopt to everyone else who does it wrong.

Maybe there are channels to the other browsers' devs to at least try advocating that they fix it on their end.

Comment 5

[another_sam]

I think:
1. "Evangelism" in the sense of "I talk, you listen" is not going to be enough to fix this bug before the end of the Internet. This should be negotiated.
2. If it's going to be negotiated, all the parts should know the pros and cons exposed by the other parts regarding their current positions.
3. A common position should be seek.
4. In the happy event of a common position reached, that should be then written down into the spec.
5. With everyone _willing_ to do what it is _written in the spec_, the fix of this bug should be then a matter of weeks.

Implicit in the above: I personally underestimate anything near "Eventually they will realize that they are wrong". Please work together with these people. Otherwise this bug will remain open for years.

Comment 6

[Robert Longson [:longsonr]]

I suggest you use the specification link http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#event-input-change and submit a review comment. If the specification is made more clear it's likely other UAs will follow it in time.

Comment 7

[Markus Popp]

(In reply to Robert Longson from comment #6)
> I suggest you use the specification link
> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-
> element-attributes.html#event-input-change and submit a review comment. If
> the specification is made more clear it's likely other UAs will follow it in
> time.

Did do so: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21377

Comment 8

[Mounir Lamouri (:mounir)]

The specifications have been changed to make it clearer that Chrome and IE are wrong:
http://html5.org/r/7787

Thank you for reporting the bug here and at the specifications Markus :)

Comment 10

[Stephan Sokolow]

Ok, if bug 858917 is a duplicate of this, then I'd like to dispute the relationship between mouse and keyboard interpretations of "when the user let go of the knob, committing to a specific value".

Developers implement onchange rather than oninput because they test with the mouse and see it behaving the way they expect. In its current version, it's a recipe for a LOT of sites with broken keyboard interaction.

For a keypress-initiated change, it makes more sense for onchange to fire after each keypress, rather than duplicating the behaviour of onblur.

...or, if you want to be consistent but silly, I suppose you could consistently interpret onblur as "committing to a specific value" and make onchange useless for mouse interaction too.