RESOLVED FIXED Bug 57723
Spinbuttons on [type="number"] etc. with [step="any"] do not work
https://bugs.webkit.org/show_bug.cgi?id=57723
Summary Spinbuttons on [type="number"] etc. with [step="any"] do not work
alexander farkas
Reported 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).
Attachments
Patch (17.80 KB, patch)
2011-06-29 01:33 PDT, Shinya Kawanaka
no flags
Patch (18.96 KB, patch)
2011-06-30 02:03 PDT, Shinya Kawanaka
no flags
Patch (18.90 KB, patch)
2011-07-04 23:24 PDT, Shinya Kawanaka
no flags
Kent Tamura
Comment 1 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.
Joseph Pecoraro
Comment 2 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?
Shinya Kawanaka
Comment 3 2011-06-29 01:33:57 PDT
Kent Tamura
Comment 4 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().
Shinya Kawanaka
Comment 5 2011-06-30 02:03:15 PDT
Kent Tamura
Comment 6 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?
Shinya Kawanaka
Comment 7 2011-07-04 23:24:41 PDT
Kent Tamura
Comment 8 2011-07-04 23:37:08 PDT
Comment on attachment 99670 [details] Patch Great patch. Thank you!
WebKit Review Bot
Comment 9 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>
WebKit Review Bot
Comment 10 2011-07-05 00:18:19 PDT
All reviewed patches have been landed. Closing bug.
Kent Tamura
Comment 11 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.
Note You need to log in before you can comment on or make changes to this bug.