Bug 16990 - Setting value attribute on an <input type=range> to an out-of-range value fires oninput
Summary: Setting value attribute on an <input type=range> to an out-of-range value fir...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Keywords: HasReduction, InRadar
Depends on: 36259
  Show dependency treegraph
Reported: 2008-01-23 16:45 PST by Adam Roben (:aroben)
Modified: 2010-03-19 09:46 PDT (History)
5 users (show)

See Also:

testcase (500 bytes, text/html)
2008-01-23 16:46 PST, Adam Roben (:aroben)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Roben (:aroben) 2008-01-23 16:45:43 PST
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.
Comment 1 Adam Roben (:aroben) 2008-01-23 16:46:00 PST
Created attachment 18630 [details]
Comment 2 Adam Roben (:aroben) 2008-01-23 16:46:43 PST
Comment 3 Adam Roben (:aroben) 2008-01-23 16:51:52 PST
It seems strange to me that RenderSlider is doing bounds checking at all. I'd expect HTMLInputElement to take care of all of that.
Comment 4 Joseph Pecoraro 2010-03-17 16:47:41 PDT
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.
Comment 5 Joseph Pecoraro 2010-03-17 16:58:03 PDT
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.
Comment 6 Joseph Pecoraro 2010-03-17 18:22:47 PDT
I believe this is related to:
Comment 7 Joseph Pecoraro 2010-03-19 09:46:46 PDT
Corrected by other change.
New test was added for this:


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)