16990 2008-01-23 16:45:43 -0800 Setting value attribute on an <input type=range> to an out-of-range value fires oninput 2010-03-19 09:46:46 -0700 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) All All RESOLVED FIXED HasReduction, InRadar P2 Normal --- 36259 1 aroben webkit-unassigned adele arv ddkilzer joepeck tkent oldest_to_newest 68078 0 aroben 2008-01-23 16:45:43 -0800 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. 68079 1 18630 aroben 2008-01-23 16:46:00 -0800 Created attachment 18630 testcase 68080 2 aroben 2008-01-23 16:46:43 -0800 <rdar://problem/5703512> 68081 3 aroben 2008-01-23 16:51:52 -0800 It seems strange to me that RenderSlider is doing bounds checking at all. I'd expect HTMLInputElement to take care of all of that. 201038 4 joepeck 2010-03-17 16:47:41 -0700 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. 201044 5 joepeck 2010-03-17 16:58:03 -0700 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. 201104 6 joepeck 2010-03-17 18:22:47 -0700 I believe this is related to: https://bugs.webkit.org/show_bug.cgi?id=36259 201901 7 joepeck 2010-03-19 09:46:46 -0700 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 18630 2008-01-23 16:46:00 -0800 2008-01-23 16:46:00 -0800 testcase slider-value-oninput.html text/html 500 aroben PHNjcmlwdD4KdmFyIHZhbCA9IDU7CmZ1bmN0aW9uIGxvZyhtc2cpIHsgZG9jdW1lbnQuZ2V0RWxl bWVudEJ5SWQoJ2xvZycpLmFwcGVuZENoaWxkKGRvY3VtZW50LmNyZWF0ZVRleHROb2RlKG1zZyAr ICdcbicpKTsgfQpmdW5jdGlvbiB0ZXN0KCkgeyBkb2N1bWVudC5nZXRFbGVtZW50c0J5VGFnTmFt ZSgnaW5wdXQnKVswXS52YWx1ZSA9IDIwMDsgfQo8L3NjcmlwdD4KPHA+VGhpcyBwYWdlIHRlc3Rz IHRoYXQgc2V0dGluZyB0aGUgdmFsdWUgb2YgYW4gPHR0PiZsdDtpbnB1dCB0eXBlPXJhbmdlJmd0 OzwvdHQ+IGVsZW1lbnQgdG8gYW4gb3V0LW9mLXJhbmdlIHZhbHVlIGRvZXMgbm90IGZpcmUgdGhl IDx0dD5vbmlucHV0PC90dD4gZXZlbnQuPC9wPgo8aW5wdXQgdHlwZT1yYW5nZSBvbmlucHV0PSJs b2coJ0ZBSUwnKSIgbWluPTAgbWF4PTEwMCB2YWx1ZT01MD4KPGJ1dHRvbiBvbmNsaWNrPSJ0ZXN0 KCkiPkNsaWNrIG1lITwvYnV0dG9uPgo8cHJlIGlkPSJsb2ciPjwvcHJlPgo=