Bug 244206 – stepUp/stepDown behavior for number inputs is inconsistent with up/down arrow keys presses

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Forms

To reproduce:
1. Create input element: `<input id="my-input" type="number"></input>`
2. Set a fractional value: `$('#my-input').value = '12.34'`
3. Focus the input and press the 'ArrowUp' key
4. See value is now `13`

5. Repeat steps 1 and 2
6. Call stepUp: `$('#my-input').stepUp()`
7. See value is now `13.34`, where I'd expect the value to be `13`

The behavior is similarly inconsistent with stepDown and ArrowDown. I tried setting explicit step values and calling stepUp/stepDown with explicit modifiers, it doesn't seem to make a difference.

[Karl Dubost]

Firefox and Chrome are consistent (rounding always to the first integer)
Safari is the outlier here. 

The spec for stepUp()/stepDown is
https://html.spec.whatwg.org/multipage/input.html#dom-input-stepup


https://html.spec.whatwg.org/multipage/input.html#the-step-attribute
> The step attribute indicates the granularity that is expected (and required) of the value or values, by limiting the allowed values. The section that defines the type attribute's current state also defines the default step, the step scale factor, and in some cases the default step base, which are used in processing the attribute as described below.

which links to https://html.spec.whatwg.org/multipage/input.html#concept-input-apply


So let's take
data:text/html,<input%20id="my-input"%20type="number"></input>

$('#my-input').step     -> ""
$('#my-input').validity.stepMismatch -> false
$('#my-input').value = '12.34'
$('#my-input').step     -> ""
$('#my-input').validity.stepMismatch -> true
$('#my-input').stepUp()
$('#my-input').value    -> "13.34"
$('#my-input').step     -> ""


Still in https://html.spec.whatwg.org/multipage/input.html#the-step-attribute
2. Otherwise, if the attribute is absent, then the allowed value step is the default step multiplied by the step scale factor.


In this case this is defined for number in https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number):concept-input-step-scale

> The step scale factor is 1. The default step is 1 (allowing only integers to be selected by the user, unless the step base has a non-integer value).

And then it goes on saying

> When the element is suffering from a step mismatch, the user agent may round the element's value to the nearest number for which the element would not suffer from a step mismatch. If there are two such numbers, user agents are encouraged to pick the one nearest positive infinity.

and in https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#suffering-from-a-step-mismatch

Suffering from a step mismatch
* When a control has a value that doesn't fit the rules given by the step attribute.
* When the setValidity() method sets stepMismatch flag to true for a form-associated custom element.


It seems like Safari should be rounding the value with stepUp()


I guess the two algorithms

* ExceptionOr<void> InputType::applyStep
https://searchfox.org/wubkat/rev/340573c924b370891b7a0794ef39d4995d3670ee/Source/WebCore/html/InputType.cpp#1011

* void InputType::stepUpFromRenderer(int n)
https://searchfox.org/wubkat/rev/340573c924b370891b7a0794ef39d4995d3670ee/Source/WebCore/html/InputType.cpp#1089

Maybe from Bug 236134 (or was it before)
https://github.com/WebKit/WebKit/commit/bde11eedef109ec600c317cc12bc793c7d6f6e5b
https://bugs.webkit.org/show_bug.cgi?id=236134

[Radar WebKit Bug Importer]

<rdar://problem/99281940>

[Ahmad Saleem]

@Karl - I think this is also fixed, can you retest it? I did your steps in Safari 18.2 and Chrome Canary 134 and got same outputs.

[Karl Dubost]

This is fixed indeed.