Setting the value attribute on an <input type=range> to an out-of-range value fires oninput. According to Web Forms <http://www.whatwg.org/specs/web-forms/current-work/#the-change>:
> [The input] event must be fired on a control whenever the value of the control changes due to input from the user
which sounds like we should not be firing this event in this case, since it's not due to input from the user.
Created attachment 18630 [details]
It seems strange to me that RenderSlider is doing bounds checking at all. I'd expect HTMLInputElement to take care of all of that.
I was looking at refactoring some of this code, the fact that RenderSlider does the bounds checking has more far reaching affects. For instance in one of the LayoutTests:
An <input> element is created but not added to the page, thus has no renderer, and the deferred RenderSlider bounds checking never gets reached. Modifying the test to append the input to the document.body enables the renderer code path and tests start to fail! I'll see if I can make sense of what the real test values should be.
History shows a few FIXMEs in the area and a mention of a potential problem in the ChangeLog:
> (WebCore::RenderSlider::updateFromElement): Added code to immediately update the value
> in the element if it's out of range. This clamping used to be done as a side effect of
> setPositionFromValue. Also, this has nothing to do with the renderer, so at some point
> it could be moved into HTMLInputElement.
Tests were added later when other input types were added, so I think the range input values were assumed to be correct at that time.
I believe this is related to:
Corrected by other change.
New test was added for this:
r56242 = 1569c5e33346f0e1681d92a925be02480504e8d5 (trunk)