[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