[Webkit-unassigned] [Bug 244206] stepUp/stepDown behavior for number inputs is inconsistent with up/down arrow keys presses

[bugzilla-daemon at webkit.org]

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

Karl Dubost <karlcow at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |BrowserCompat
                 CC|                            |karlcow at apple.com,
                   |                            |zsun at igalia.com

--- Comment #1 from Karl Dubost <karlcow at apple.com> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220823/b7753a08/attachment.htm>