1939377 - Add back the ability to scroll to increase/decrease number text fields, with the same constraints as other browsers around "wheel" event-listeners

Status: ASSIGNED

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Ilyas Kaya]

Steps to reproduce:

Go to; https://genshin-center.com/planner
Create any weapon, click on an item to bring a pop-up, and try to use the scroll wheel on the input fields.

Actual results:

Nothing

Expected results:

The number increases/decreases based on the scroll.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Form Autofill' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alice0775 White]

This behavior was disabled by default since Firefox130 and ESR128. See Bug 1741469.
Setting dom.input.number_and_range_modified_by_mousewheel to true then it works for me.

Comment 3

[juraj.masiar]

Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu.
So it's actually inconsistency bug and the regression is the bug 1741469.

Comment 4

[Theodore]

Hopefully Chrome/Edge will remove this "feature", as it is the source of many issues where users accidentally submit a form with the wrong amount, since the value they entered changed when scrolling.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to juraj.masiar from comment #3)

Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu.

Can you add detail on where you're seeing inputs change value on scrolling? In particular, do you see the inputs changing value in testcase 1 or 2?
[edit: I meant testcase 1 or 2 on bug 1741469]

I retested today in Chrome/Edge on Windows 11, and I confirmed the inputs in those testcases are not changing value for me (though they previously were changing when mousewheel-scrolled in Firefox, prior to bug 1741469).

I can confirm that I do see Chrome/Edge changing the number on the website in comment 0, though (on the "refinement" number-input field in the add-weapon UI). And I do see a related Chromium bug report that mentions onwheel and has some clues about what is actually required to trigger this input-field-mutation behavior there -- apparently Chromium triggers this behavior if there's an element with onwheel whose hit-test region overlaps the number field, for some reason?
https://issues.chromium.org/issues/40859979#comment8

Here's a testcase to demonstrate that:

data:text/html,<div onwheel><input type="number"></div><div><input type="number"></div>

In Chrome on my Win11 machine, only the first element there has its value modified by mousewheel-scrolling.

Comment 6

[Daniel Holbert [:dholbert]]

In the genshin-center.com example linked in comment 0, there's no onwheel attribute, but rather an event-listener for the wheel event, which seems to also activate the number-value-mutation behavior in Chrome.

I'll attach a testcase to demonstrate that behavior (in Chrome).

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (demonstrating how Chrome activates this behavior if-and-only-if there's a 'wheel' event listener)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast showing Chrome on testcase 1

Here's a screencast showing me interacting with testcase 1 in Chrome. I'm mousewheel scrolling when I hover the (focused) input field. The value doesn't change at the start of the video, but it does change at the end (after I've added the event listener).

Comment 9

[Daniel Holbert [:dholbert]]

I just tested several other browser-versions, and they all behave as-shown the screencast in comment 8 (i.e. mousewheel has no effect until I add a 'wheel' event listener):

• Chrome 133 dev (current) on Linux
• Chrome 55 on Win 10 (roughly the timeframe when we implemented this feature in bug 1261673)
• Safari 18.1 on macOS Sequoia

So it looks like our implementation in bug 1261673 was overly broad, at least with respect to what's implemented in other browsers (and what was implemented at-the-time in Chromium at least).

If we want to add this feature back (for feature parity on sites that opt into it via a wheel event listener), we won't want to simply toggle the pref (reverting bug 1741469) because that makes the feature too much of a footgun, as described in bug 1741469. We would need to rework it to have the same constraints as other browsers, around whether there's a wheel event-listener, so that hopefully only sites that are interested in this wheel-based-mutation will be opening themselves up to it.

I'll leave that to folks on the DOM team if they're interested; my involvement here (in bug 1741469) was just in switching off our preexisting footgunny version of the feature, since as described there, it caused unwanted behavior in all sorts of cases where Chrome/Safari do nothing.

Comment 10

[Daniel Holbert [:dholbert]]

I'll adjust the title to narrow/clarify the request here (if we decide to take action on it).

Comment 11

[juraj.masiar]

Thank you Daniel for the deep analysis of the situation!
My test case indeed had a "seemingly unrelated" wheel handler on one of the parents.

Happy new year! 🎉

Comment 12

[Arun Das]

I can see why this is useful for this particular use case in the linked website "Ascension Planner - Genshin Center". The UI shown when adding a weapon is a small non-scrolling modal, where scrolling with the wheel would be quite useful to quickly choose values. I see it working with the wheel in the regular numeric input "Refinement". (Note: I'm using Chrome browser.)

However, it's also inconsistent, as a numeric input with a dropdown doesn't change value when using the mouse wheel. (It doesn't work with "Current" and "Desired" inputs.)

IMHO, this "wheel to change numeric input" should be turned OFF by default in all browsers, then 👉 opted-in by developers 👈 on a case-by-case basis in specific rare cases where it makes sense. Either by an attribute on the input or by manually handling the wheel event (unfortunately, it's not available in Safari yet).

Because more often than not, it doesn't make sense for the mouse wheel to change numeric input, and it causes imperceptible erroneous input when scrolling a form up and down and accidentally hovering the mouse on a numeric input.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Daniel Holbert [:dholbert] from comment #9)

I just tested several other browser-versions, and they all behave as-shown the screencast in comment 8 (i.e. mousewheel has no effect until I add a 'wheel' event listener):

• Chrome 133 dev (current) on Linux
• Chrome 55 on Win 10 (roughly the timeframe when we implemented this feature in bug 1261673)
• Safari 18.1 on macOS Sequoia

So it looks like our implementation in bug 1261673 was overly broad, at least with respect to what's implemented in other browsers (and what was implemented at-the-time in Chromium at least).

Hi Edgar,
Maybe you can help us check first about what the spec says for this case? Should we file a spec issue to clarify the behavior?

If we want to add this feature back (for feature parity on sites that opt into it via a wheel event listener), we won't want to simply toggle the pref (reverting bug 1741469) because that makes the feature too much of a footgun, as described in bug 1741469. We would need to rework it to have the same constraints as other browsers, around whether there's a wheel event-listener, so that hopefully only sites that are interested in this wheel-based-mutation will be opening themselves up to it.

I'll leave that to folks on the DOM team if they're interested; my involvement here (in bug 1741469) was just in switching off our preexisting footgunny version of the feature, since as described there, it caused unwanted behavior in all sorts of cases where Chrome/Safari do nothing.

Comment 14

[Ilyas Kaya]

I had thought this was a simple bug, but I guess it rarely ever is the case. Thank you Daniel for the analysis!

In my opinion, I think this should be reverted to allowing the scroll value by default but only work when in focus and hover to avoid those miss inputs that seem to have caused this to be removed (personally, never had it... skill issue?).

Comment 15

[Theodore]

I think this should be reverted to allowing the scroll value by default but only work when in focus and hover to avoid those miss inputs that seem to have caused this to be removed

I don't think that is enough to prevent accidentally changing the input. Consider that a user will click in a number input to enter a value, making it hovered and focused. After typing a number, scrolling to view the next field would then cause the value to be inadvertently changed.

Comment 16

[juraj.masiar]

The accidental modification is quite rare only when you are using mouse, but if you are using touchpad, the cursor may not move when you use two fingers gesture to scroll, so it will indeed change the input instead.

That said, not every input on the web is a form, and there is many useful cases when this is a big plus (not being forced to use keyboard just to increment a value by one).

Also, making a polyfil by a webpage developer is quite impossible, since you don't know whether the browser incremented the value for you or not.

So I'm 100% for copying the Chrome/Safari behavior (with the "wheel" handler detection), thus making the web-devs life easier.

Comment 17

[Ilyas Kaya]

Agreed. I just tested a bunch, and I had to go out of my way to accidentally change the value with a scroll wheel. No comment for trackpad as I always have a mouse even on my laptop.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Ilyas Kaya from comment #17)

Agreed. I just tested a bunch, and I had to go out of my way to accidentally change the value with a scroll wheel.

I think we're in agreement that there should be some sort of interoperable opt-in mechanism here, per end of comment 16, but I just need to push back gently on this point about this issue being hard to trigger -- even if it's rare, it does happen accidentally, at least for some users (including me); and when it does happen, consequences can be pretty terrible and can have real-world consequences. e.g. inadvertently changing digits in your contact info in a web-form where you're urgently expecting a message back (which will now never arrive since you provided bad contact info); or inadvertently increasing a "quantity" field when placing an order for some expensive item and being billed/shipped the wrong amount; or changing some field in a web-based tax-form where incorrect information has legal and/or financial consequences.

This is particularly bad because the unwanted modification can happen just after the user has visually verified that the value is (er, was) correct, e.g. if the user is moving their mouse to hover each field as they visually check it for correctness; and then they scroll down to submit, & inadvertently change the value after they've verified it.

Comment 19

[Daniel Holbert [:dholbert]]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #13)

Hi Edgar,
Maybe you can help us check first about what the spec says for this case?

Edgar can weigh in too of course, but FWIW here's what I've gathered:

I don't think the mousewheel/scrolling-based value-modification-behavior is officially specced at all, or at least I can't find it. The main spec text for input type="number" is here, I think:
https://html.spec.whatwg.org/multipage/input.html#number-state-(type=number)
https://html.spec.whatwg.org/multipage/rendering.html#the-input-element-as-domain-specific-widgets
...and there's no mention of scroll or wheel that I'm seeing in either of those sections.

Having said that: I think the intent in all browsers was originally for it to work the way that that we implemented it, and the unexpected-modification footgun (bug 1741469) simply wasn't foreseen or wasn't expected to be as much of a problem as it actually is. And in other browsers, that footgun didn't end up causing too much trouble because they accidentally have this behavior guarded behind the aforementioned wheel-event, which turned out to function as a clumsy opt-in mechanism. (I think that mechanism is unintentional and considered to be a bug in other engines, per https://bugs.webkit.org/show_bug.cgi?id=244240#c3 and https://issues.chromium.org/issues/40859979#comment8 , but it's persisted and they don't seem eager to fix it; and at this point it seems wise to keep that or some other sort of interoperable opt-in signal from the developer, to avoid issues like those described in comment 18.)

Should we file a spec issue to clarify the behavior?

That's probably worth doing. In the meantime, unless we've got buy-in from other browsers on a graceful opt-in mechanism, we might want to implement a more-direct and perhaps more-limited version of the wheel-based opt-in mechanism that they currently accidentally have. (e.g. maybe we should activate this behavior iff the input element itself has a wheel event-listener.)

Comment 20

[Edgar Chen [:edgar]]

I filed https://github.com/whatwg/html/issues/10911. And I also found something we need to address as well

• On macOS (and also Android), we don’t prevent the page from scrolling when the input element handles the wheel event. I think we should make this behavior consistent with other platforms.
• Chrome and Safari don’t support scrolling to change the input value for the range type now.

Comment 21

[Edgar Chen [:edgar]]

Attachment: Bug 1939377 - Part 1: Stop supporting value changes for range inputs when scrolling the mouse wheel; r?smaug,dholbert

As other browsers no longer support this either.

Comment 22

[Edgar Chen [:edgar]]

Attachment: Bug 1939377 - Part 2: Prevent APZ from handling the wheel event when it is handled on input element on all platform; r?smaug,dholbert

Comment 23

[Edgar Chen [:edgar]]

Attachment: Bug 1939377 - Part 3: Activate scroll-to-change behavior for number inputs only when they have wheel event listeners registered; r?smaug,dholbert

Comment 24

[Edgar Chen [:edgar]]

Attachment: Bug 1939377 - Part 4: Enable dom.input.number_and_range_modified_by_mousewheel again; r?smaug,dholbert

Comment 25

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #9)

I just tested several other browser-versions, and they all behave as-shown the screencast in comment 8 (i.e. mousewheel has no effect until I add a 'wheel' event listener):

• Chrome 133 dev (current) on Linux
• Chrome 55 on Win 10 (roughly the timeframe when we implemented this feature in bug 1261673)
• Safari 18.1 on macOS Sequoia ested; my involvement here (in bug 1741469) was just in switching off our preexisting footgunny version of the feature, since as described there, it caused unwanted behavior in all sorts of cases where Chrome/Safari do nothing.

I tested some older Chrome/Safari versions today and found that they didn't have the inadvertent wheel opt-in mechanism. The first version I could find with the opt-in was Safari 6.2 and Chrome 41. (Safari 6.0 and Chrome 40 matched the way that we shipped this feature in https://bugzilla.mozilla.org/show_bug.cgi?id=1261673 as best I can tell.)

I added some notes in https://bugs.webkit.org/show_bug.cgi?id=244240 and https://issues.chromium.org/issues/40859979 to alert the Chrome and Safari teams to the timeframe of this historical change that they (inadvertently?) made, and I also let them know about the spec issue.

Comment 26

[Daniel Holbert [:dholbert]]

(In reply to Edgar Chen [:edgar] from comment #20)

• Chrome and Safari don’t support scrolling to change the input value for the range type now.

I think they never did, actually. In my testing of old Chrome/Safari versions today, I didn't find any versions that supported changing the value of input type="range" (whether or not there was a wheel event listener). Our bug 1261674 comment 0 seems to have drawn inspiration from GTK and Qt, and didn't mention other browsers, I guess. Given that no other browsers adopted this behavior, it seems fine to drop it at this point.

Comment 27

[Daniel Holbert [:dholbert]]

(In reply to Edgar Chen [:edgar] from comment #20)

• On macOS (and also Android), we don’t prevent the page from scrolling when the input element handles the wheel event.

Whoops, that's my mistake I think. In https://hg.mozilla.org/integration/autoland/rev/e596940bc7d8#l1.12 I had ported some mac/android ifdefs to be pref-checks instead (since before that point this was unconditionally on for Windows/Linux and unconditionally off for Android/Mac, and my intent was to just switch those ifdefs to be pref-checks, with the ability to have different pref-default-values per platform if we wanted to take baby steps towards turning this back on).

Looks like I missed some ifdefs though, and you've found them and fixed them up in part 2 here. Thanks!

Comment 28

[Daniel Holbert [:dholbert]]

(In reply to juraj.masiar from comment #16)

Also, making a polyfil by a webpage developer is quite impossible, since you don't know whether the browser incremented the value for you or not.

Good news: I think polyfills aren't that much trouble, because you can prevent the browser from incrementing the value for you. You just need event.preventDefault() in your wheel handler. (You probably want this anyway to prevent scrolling; but it happens to also prevent number modification, based on my testing just now in Chrome/Safari.)

I'll post a testcase as a demonstration of this.

Comment 29

[Daniel Holbert [:dholbert]]

Attachment: demo of polyfill

Here's a demo of what folks could use as a polyfill here. The first number field here is the demonstration of "good" behavior, and the second one is an anti-pattern just for demonstration.

In this case I'm setting things up to increment/decrement the number field by 50 on each mousewheel-tick. Firefox, Chrome, and Safari all do exactly that (increment/decrement by 50) on my mousewheel-spin for the first number field -- they adjust the field by exactly 50, without any additional adjustment from the browser.

On the second number field here (the anti-pattern, where I don't call preventDefault()), I do see the issue that comment 16 alluded to -- Chrome, Safari, and Firefox-with-dom.input.number_and_range_modified_by_mousewheel-enabled all do an additional +1/-1 adjustment, from the browser doing its own wheel-handling.

So: preventDefault is an effective mitigation for that issue.

Comment 30

[Daniel Holbert [:dholbert]]

I mentioned this in one of the phabricator reviews, but I'll note here as well: we might want to hold off on landing here (or at least hold off on the reenabling pref-flip in part 4) because WebKit folks are now actively looking to remove this feature (matching current Firefox Nightly). References:
https://github.com/whatwg/html/issues/10911#issuecomment-2607073755
https://github.com/WebKit/WebKit/pull/39382
https://bugs.webkit.org/show_bug.cgi?id=244240#c11