Specify the ability to scroll to increase/decrease <input type=number>

[EdgarChen]

What is the issue with the HTML Standard?

Both Chrome and Safari support increasing or decreasing the value of <input type=number> by scrolling the mouse wheel only when

• input element need to be focused.
• The mouse wheel scroll must occur while hovering over the input.

And they now provide an opt-in mechanism (perhaps unexpectedly ?),

• input element must have a wheel or mousewheel event handler registered.
  See the example of https://bug1939377.bmoattachments.org/attachment.cgi?id=9445400

We attempted to implement the same behavior without the opt-in mechanism in Gecko in bug 1261673 (I believe other browsers behaved like that at the time). However, we realized it might be a footgun as users might accidentally submitted a form with the wrong amount because of this and the original case in bug 1261673 doesn't work on other browser anymore, so we disabled this behavior in bug 1741469.

Now, we’ve noticed Chrome/Safari have an opt-in mechanism (not sure if it is intentional though as they are now considered a bug per https://bugs.webkit.org/show_bug.cgi?id=244240#c3 and https://issues.chromium.org/issues/40859979#comment8). However, this opt-in mechanism has likely prevented scroll-to-change-input-value from causing too much trouble.

It would be nice to specify the expected behavior in the spec to ensure consistency across browsers.

[annevk]

cc @whatwg/forms

[dholbert]

A few minor clarifications:

Both Chrome and Safari support increasing or decreasing the value of <input type=number> by scrolling the mouse wheel [...]
And they now provide an opt-in mechanism (perhaps unexpectedly ?),

* input element must have a `wheel` or `mousewheel` event handler registered.
  See the example of https://bug1939377.bmoattachments.org/attachment.cgi?id=9445400

Nit: strictly speaking, Chrome/Safari also seem to support modifying the number-field if there's some other element that contains/overlaps the input element that has a wheel/mousesheel event-handler registered. (see e.g. https://bugs.webkit.org/show_bug.cgi?id=244240#c3 )

But ideally if we were to formalize this opt-in, then I think it would make sense to condition this on the input element itself.

We attempted to implement the same behavior without the opt-in mechanism in Gecko in bug 1261673 (I believe other browsers behaved like that at the time).

Back when we implemented, other browsers had the same bug (same accidental opt-in) as they do today, FWIW -- at least, I confirmed that this is true for Chrome 55 (released in 2016) per https://bugzilla.mozilla.org/show_bug.cgi?id=1939377#c9

EDIT: going back further in history, though, it looks there was actually a point in history where other browsers lacked the event-listener-based opt-in mechanism.
Safari: Safari 6.0 didn't require any event listener opt-in here, vs. Safari 6.2 did.
Chrome: Chrome 40 didn't require any event listener opt-in here, vs . Chrome 41 did.

This was likely an unintended change, but it's brought us to the world we live in now. :)

[WickyNilliams]

Something to consider if this officially becomes opt-in via a wheel event. Many people didn't want this behavior and sought to avoid it. The suggested fixes you find online generally consist of recommending something like this:

<input type="number" id="input">
<script>
  input.addEventListener("wheel", e => e.preventDefault())
</script>

So if this becomes conditional on the presence of a wheel event, the people who previously used wheel to avoid the behavior would now be opting into that behavior instead.

[annevk]

Colleagues and I discussed this and are considering removing this functionality as it doesn't match any of Apple's platform behaviors. It also doesn't seem that useful.

Was there a particular reason Firefox wanted to match this functionality?

[WickyNilliams]

Adding a little detail, since I've been investigating this behavior today. React eagerly adds a wheel listener to your app's root, meaning you are always opted into this behavior in the context of React 😬

[dholbert]

Was there a particular reason Firefox wanted to match this functionality?

Not especially -- just for interop with Chrome/Safari, mostly. We just got a bug report after we turned off this functionality, where a user was expecting mousewheel-scrolling to change the focused number-field's value (on a site that happened to have a wheel event-listener on the number field), because it was working in Chromium/WebKit and had been working in Firefox until recently. It's not entirely clear if the site expects/intends for this to happen, but the user at least noticed that it had stopped working in Firefox and perceived that as a bug. Here's a screencast of the user's expected-results in Chrome:
https://github.com/user-attachments/assets/7a2160f7-e9c2-4871-85e4-22839d1d4d33

[dholbert]

We also had a bug-comment with some worries that this behavior might be impossible for webdevs to polyfill, precisely because of the fact that browsers do this on their own (and hence the browsers' value-adjustment might stack on top of the site's value-adjustments). That concern had led me to believe we needed to align on this, so that authors-who-want-this-behavior could have a way to get it.

However: I just attempted a polyfill and found that this concern isn't actually an issue; e.preventDefault() successfully bypasses the browser's increment, as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1939377#c28 and the following comment (with a testcase).

[sfortiner]

I wrote a series of test pages for this with various wheel event listeners. You can find it here: https://harmonious-quaint-cat.glitch.me/.

Based on the behavior I'm seeing in Chromium, it seems that wheel event listeners are passive: false by default (vs passive: true like normal) when applied to a input type="number" element. If you modify it to be passive: true then you get the undesirable behavior of a wheel both changing the value and scrolling the page. This applies even if the element with the passive listener is not the input element. I also found e.preventDefault() blocks the browser behavior of modifying the value. In all cases, unless the input element is focused and the mouse is over the input element, no value change happens.

[mustaqahmed]

We in Blink observed the same thing @sfortiner observed, and this feels more like a bug than a deliberate opt-in mechanism.

The facts that WebKit has removed the wheel event behavior and Firefox didn't have this behavior in the past suggest to me Blink should probably do the same. For sake of compat, I would love to know why React has the "opt-in" @WickyNilliams mentioned...anyone knows?

[WickyNilliams]

I think it's a result of their synthetic event system. I raised an issue in the react repo here facebook/react#32156