Bug 57723

Summary: Spinbuttons on [type="number"] etc. with [step="any"] do not work
Product: WebKit Reporter: alexander farkas <info>
Component: FormsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Enhancement CC: ap, info, joepeck, tkent, webkit.review.bot
Priority: P3    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

Description alexander farkas 2011-04-03 01:29:47 PDT
1. simply add <input type="number" step="any" />
2. Try to use the spinbuttons

The first mousepress will change the value to 0 after that, the spinnbutton doesn't work. I would suggest, if step is "any" the button "spins" the value with the default step (like it would if no step is configured).
Comment 1 Kent Tamura 2011-04-04 00:27:03 PDT
> I would suggest, if step is "any" the button "spins" the value with the default step (like it would if no step is configured).

That sounds good.
Comment 2 Joseph Pecoraro 2011-06-07 10:49:12 PDT
We could probably then fix up RangeInputType::handleKeydownEvent
which has the following comment:

    // FIXME: We can't use stepUp() for the step value "any". So, we increase
    // or decrease the value by 1/100 of the value range. Is it reasonable?
Comment 3 Shinya Kawanaka 2011-06-29 01:33:57 PDT
Created attachment 99054 [details]
Patch
Comment 4 Kent Tamura 2011-06-29 01:56:04 PDT
Comment on attachment 99054 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=99054&action=review

> Source/WebCore/ChangeLog:17
> +        * html/HTMLInputElement.cpp:
> +        (WebCore::HTMLInputElement::applyStep):
> +        (WebCore::HTMLInputElement::getAllowedValueStepWithDecimalPlacesWithAllowingStepAny):
> +        (WebCore::HTMLInputElement::stepUp):
> +        (WebCore::HTMLInputElement::stepDown):
> +        (WebCore::HTMLInputElement::stepUpFromRenderer):
> +        * html/HTMLInputElement.h:

You should write summaries of changes in each of files/functions.

> Source/WebCore/html/HTMLInputElement.cpp:380
> +void HTMLInputElement::applyStep(double count, bool allowsStepAny, ExceptionCode& ec)

Do not introduce bool parameter.  We prefer enum to bool strongly.
e.g.
enum AnyStepHandling { RejectAny, AnyIsDefaultStep };

> Source/WebCore/html/HTMLInputElement.cpp:443
> +    ASSERT(step);
> +    double defaultStep = m_inputType->defaultStep();
> +    double stepScaleFactor = m_inputType->stepScaleFactor();
> +    if (!isfinite(defaultStep) || !isfinite(stepScaleFactor))
> +        return false;

This part is duplicate with getAllowedValueStepWithDecimalPlaces().  It's not good.

The difference between this function and getAllowedValueStepWithDecimalPlaces() is only "any" handling. I think it's ok to add the enum parameter to getAllowedValueStepWithDecimalPlaces().
Comment 5 Shinya Kawanaka 2011-06-30 02:03:15 PDT
Created attachment 99260 [details]
Patch
Comment 6 Kent Tamura 2011-06-30 02:18:44 PDT
Comment on attachment 99260 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=99260&action=review

> Source/WebCore/html/HTMLInputElement.h:67
> +    bool getAllowedValueStepWithDecimalPlaces(AnyStepHandling, double*, unsigned*) const;

Can you make getAllowedValeuStepWithDecimalPlaces() and AnyStepHandling private?
Comment 7 Shinya Kawanaka 2011-07-04 23:24:41 PDT
Created attachment 99670 [details]
Patch
Comment 8 Kent Tamura 2011-07-04 23:37:08 PDT
Comment on attachment 99670 [details]
Patch

Great patch.  Thank you!
Comment 9 WebKit Review Bot 2011-07-05 00:18:14 PDT
Comment on attachment 99670 [details]
Patch

Clearing flags on attachment: 99670

Committed r90385: <http://trac.webkit.org/changeset/90385>
Comment 10 WebKit Review Bot 2011-07-05 00:18:19 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Kent Tamura 2011-07-05 00:29:40 PDT
(In reply to comment #2)
> We could probably then fix up RangeInputType::handleKeydownEvent
> which has the following comment:
> 
>     // FIXME: We can't use stepUp() for the step value "any". So, we increase
>     // or decrease the value by 1/100 of the value range. Is it reasonable?

I'm not sure if assuming "any" 1.0 for type=range is better.  We have another issue about keyboard operation with the default step, Bug 63574.