[Webkit-unassigned] [Bug 45491] when empty, clicking "down" on outer-spin-button returns "max value"
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Nov 25 17:46:17 PST 2010
https://bugs.webkit.org/show_bug.cgi?id=45491
--- Comment #23 from Dai Mikurube <dmikurube at google.com> 2010-11-25 17:46:17 PST ---
(From update of attachment 74839)
View in context: https://bugs.webkit.org/attachment.cgi?id=74839&action=review
Thank you for the comments.
It's just a reply. No new patch is attached yet. I'll attach it after adding some test cases.
>> JavaScriptCore/ChangeLog:20
>> + Finally I locked "milliseconds" in non-UTC in calculating default values.
>
> This paragraph looks unnecessary.
> Also, I feel it's strange to have the word "I" in ChangeLog.
Removed.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:1
>> +description('Check stepUp() and stepDown() bahevior from renderer for type=date, datetime, datetime-local, month, time, week.');
>
> The test contains "number" and "range" types.
Done.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:88
>> +shouldBe('stepDown("2010-02-10", null, null, null)', '"2010-02-10"');
>
> The 4th parameter is recognized in JavaScript code and is not passed to C++ code.
> We don't need to test invalid values.
Exactly. Removed.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:101
>> +shouldBe('stepDown("2010-02-10", "3.40282346e+38", null)', '"275760-09-13"');
>
> These results look very strange. Are they expected?
No "max" is given, so it results in the maximum number (date) for type=date under 3.40282346e+38.
The maximum number is defined in WebCore/html/DateComponent.h :
WebCore/html/DateComponents.h: static inline double maximumDate() { return 8640000000000000.0; } // 275760-09-13T00:00Z
WebCore/html/DateComponents.h: static inline double maximumMonth() { return (275760 - 1970) * 12.0 + 9 - 1; } // 275760-09
WebCore/html/DateComponents.h: static inline double maximumWeek() { return 8639999568000000.0; } // 275760-09-08, the Monday of the week including 275760-09-13.
1970-01-01 comes from the internal representation. The date is represented by 0. In this tag, the step-base is 0. So it resulted in 1970-01-01. It may be unnatural.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:114
>> +shouldBe('stepDown("2010-02-10T20:13Z", null, null, null)', '"2010-02-10T20:13Z"');
>
> ditto.
Removed. (The same for dittos.)
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:205
>> +shouldBe('input.value = "1"; input.stepDown(1, 3); input.value', '"0"');
>
> These are not related to the code change.
Right, it doesn't use stepUpFromRenderer(). Removed cases with "input.stepUp/Down".
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:212
>> +shouldBe('stepDown("0", "any", null)', '"0"');
>
> We should add test cases with empty/invalid values and invalid/any step.
Ok, adding.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:217
>> +shouldBe('input.value', '"0"');
>
> This doesn't test anything.
Right. Removed.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:224
>> +debug('stepDown()/stepUp() for stepMismatch values');
>
> Other types should have similar test cases.
Thanks. Adding.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:227
>> +shouldBe('input.min = "0"; stepUp("9", "10", "", 9)', '"90"');
>
> This looks equivalent to
> shouldBe('input.min = "0"; stepUp("9", "10", "")', '"10"');
> The 4th parameter is not needed.
Replaced.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:250
>> +debug('function arguments are (min, max, step, value, [stepCount])');
>
> Nice to have explanation of stepUp() and stepDown() too.
Added explanations.
>> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:260
>> +shouldBe('stepDownExplicitBounds(null, null, null, "0", null)', '"0"');
>
> It makes no sense to test invalid 5th parameter.
Removed.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list