[Webkit-unassigned] [Bug 45491] when empty, clicking "down" on outer-spin-button returns "max value"

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=45491


Kent Tamura <tkent at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #74984|1                           |0
        is obsolete|                            |




--- Comment #34 from Kent Tamura <tkent at chromium.org>  2010-11-28 23:01:29 PST ---
(From update of attachment 74984)
View in context: https://bugs.webkit.org/attachment.cgi?id=74984&action=review

> JavaScriptCore/ChangeLog:12
> +        Calculating milliseconds from a struct tm is not clear. timegm() cannot be used in all

I don't catch what "clear" here means.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:1
> +description('Check stepUp() and stepDown() for <input> from renderer. No cases of empty initial values for type=date, datetime, datetime-local, month, time, week.');

This is not a test for stepUp() and stepDown(), which are standard DOM API.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:89
> +debug('function arguments are (value, step, {min or max}, [stepCount])');

A sentence should start with a capital letter and end with a period.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:275
> +shouldBe('stepUpExplicitBounds(null, "100", "1", "100")', '"100"');
> +shouldBe('input.value', '"100"');

Checking input.value again makes no sense.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:276
> +shouldBe('stepUpExplicitBounds(null, "100", "1", "99", "2")', '"100"');

The 5th parameter doesn't need to be a string.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:277
> +shouldBe('input.value', '"100"');

Checking input.value again makes no sense.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:280
> +shouldBe('input.value', '"0"');

ditto.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:281
> +shouldBe('stepDownExplicitBounds("0", null, "1", "1", "2")', '"0"');

The 5th parameter doesn't need to be a string.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:282
> +shouldBe('input.value', '"0"');

Checking input.value again makes no sense.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:283
> +shouldBe('stepDownExplicitBounds(null, null, "3.40282346e+38", "1", "2")', '"0"');

The 5th parameter doesn't need to be a string.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:287
> +shouldBe('input.value', '"0"');

Checking input.value again makes no sense.

> LayoutTests/fast/forms/script-tests/input-stepup-stepdown-from-renderer.js:288
> +shouldBe('stepUpExplicitBounds(null, null, "3.40282346e+38", "1", "2")', '"0"');

The 5th parameter doesn't need to be a string.

> WebCore/ChangeLog:42
> +        (WebCore::BaseDateAndTimeInputType::startingValue): Added startingValue() which returns the current local time

Please update the ChangeLog.

> WebCore/ChangeLog:62
> +        * manual-tests/input-type-datetime-default-value.html: Added manual tests for default values of date/time inputs

Please add a reason why we need a manual test.

> WebCore/html/HTMLInputElement.cpp:1901
> +    int sign = n * (step < 0 ? (-1) : (1));

Inner parentheses are redundant.

> WebCore/html/HTMLInputElement.cpp:1916
> +        if (stepMismatch(currentStringValue)) {
> +            double newValue;

We had better have ASSERT(step).

> WebCore/html/RangeInputType.cpp:152
> +        // Not using stepUpFromRenderer() since it is not any kind of stepUp()
> +        // No stepUp() for step="any"

These words are unclear though I understand what you'd like to say.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.