Bug 16990 – Setting value attribute on an <input type=range> to an out-of-range value fires oninput

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Adam Roben (:aroben)]

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.

[Adam Roben (:aroben)]

Created attachment 18630 [details]
testcase

[Adam Roben (:aroben)]

<rdar://problem/5703512>

[Adam Roben (:aroben)]

It seems strange to me that RenderSlider is doing bounds checking at all. I'd expect HTMLInputElement to take care of all of that.

[Joseph Pecoraro]

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:

  LayoutTest/fast/forms/script-tests/ValidityState-rangeOverflow.js

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.

[Joseph Pecoraro]

History shows a few FIXMEs in the area and a mention of a potential problem in the ChangeLog:
http://trac.webkit.org/changeset/41972

> (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.

[Joseph Pecoraro]

I believe this is related to:
https://bugs.webkit.org/show_bug.cgi?id=36259

[Joseph Pecoraro]

Corrected by other change.
New test was added for this:

  LayoutTests/fast/forms/range-input-dynamic-oninput-expected.txt
  LayoutTests/fast/forms/range-input-dynamic-oninput.html


Committed r56242
	M	WebCore/ChangeLog
	M	WebCore/html/StepRange.h
	M	WebCore/html/HTMLInputElement.cpp
	M	WebCore/html/StepRange.cpp
	M	WebCore/rendering/RenderSlider.cpp
	M	LayoutTests/fast/forms/ValidityState-rangeOverflow-expected.txt
	M	LayoutTests/fast/forms/script-tests/ValidityState-rangeOverflow.js
	M	LayoutTests/fast/forms/script-tests/validationMessage.js
	M	LayoutTests/fast/forms/script-tests/ValidityState-rangeUnderflow.js
	M	LayoutTests/fast/forms/script-tests/input-stepup-stepdown.js
	M	LayoutTests/fast/forms/range-reset.html
	A	LayoutTests/fast/forms/range-input-dynamic-oninput-expected.txt
	A	LayoutTests/fast/forms/range-input-dynamic-oninput.html
	M	LayoutTests/fast/forms/ValidityState-rangeUnderflow-expected.txt
	M	LayoutTests/fast/forms/validationMessage-expected.txt
	M	LayoutTests/fast/forms/input-stepup-stepdown-expected.txt
	M	LayoutTests/fast/forms/range-reset-expected.txt
	M	LayoutTests/ChangeLog
r56242 = 1569c5e33346f0e1681d92a925be02480504e8d5 (trunk)
http://trac.webkit.org/changeset/56242