1780302 - <input type="number"> stepping behavior differs from Chrome when step="any"

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect, P3)

Description

[Martin Müller]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

1. Create a number input field with a fraction in either "min" or "value" attribute and another different fraction (or integer) in the other field, for example: <input type="number" min="0.01" value="2.4" />
2. Use any spinner button (up/down) to change the value.

Actual results:

The fraction part of the value gets replaced by the fraction part of the "min" attribute (or the fraction gets removed if "min" is an integer and the value is a fraction), regardless of spinner direction (up or down) even if the value is within the bounds. Example: If "value" initially is 2.4 and "min" is 0.01, the value gets 3.01 on increase via the spinner up button or the value gets 2.01 if it is decreased via the spinner down button.

Interactive code: https://jsfiddle.net/e9k0yqmL/

Expected results:

The fraction part of the value should not be replaced by the fraction part of the "min" attribute unless it meets the lower or upper bounds. E. g. if value initially is 2.4 and "min" is 0.01, the value should be 3.4 if it increased via the spinner up button or 1.4 if it is decreased via the spinner down button. This is also the behavior in other browsers like Chrome and Safari.

Comment 1

[Alice0775 White]

The behavior was introduced by Bug 1028712 / Bug 1071994.

Comment 2

[Kris Maglione [:kmag]]

This is the behavior defined in the spec. Sorry.

Comment 3

[Martin Müller]

Thanks for the pointer to the specification. On further investigation this bug only seems to be valid if "step" is set to "any". In my initial example I omitted this attribute (but not in the linked interactive code example), as for Firefox setting "step" to "any" or not setting it makes no difference in contrast to other browsers like Chrome and Safari.

According to the spec, the stepUp() and stepDown() functions should throw an "InvalidStateError" exception if step is set to "any". Maybe it is advisable to fall back to the same behavior as Chrome.

Comment 4

[Kris Maglione [:kmag]]

I'll leave it to the web compat team determine the next step here. Following a completely different algorithm when the spec says we should abort doesn't feel like the right solution.

Comment 5

[Raul Bucata]

We appreciate your report. I was able to reproduce the issue following: https://jsfiddle.net/e9k0yqmL/ . Incrementing or decrementing using Firefox changes the double value as well (e.g from 2.4 it goes to 3.01 when attempting to increment the default value, instead of incrementing to 3.4).

Tested with:

Browser / Version: Firefox Release 109.0.1 (64-bit)/ Firefox Nightly 111.0a1 (2023-02-02) (64-bit) / Chrome Version 109.0.5414.120 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac Ventura 13.1

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 7

[Dennis Schubert [:denschub]]

Let's close this as invalid. As explained, we're following the spec here. We also don't have any real-world webcompat fallout from this, and the DOM team also doesn't see a need to change. We can reconsider this is we know about real sites breaking because of this.

Comment 8

[Martin Müller]

I created this issue because I noticed that this bug affects a German website for cooking recipes: If the counter for the portion is in-/decremented a fraction gets added as initially described. E.g. test on this recipe: https://www.chefkoch.de/rezepte/1208161226570428/Der-perfekte-Pfannkuchen-gelingt-einfach-immer.html