Open Bug 1690639 Opened 3 years ago Updated 3 years ago

Scrolling mouse wheel over number text field spinner will both spin it and scroll page

Categories

(Core :: DOM: Forms, defect)

Firefox 85
defect

Tracking

()

UNCONFIRMED

People

(Reporter: send2adtc, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

If I use the mouse wheel (or simulate it using gestures like two-finger scroll on a trackpad), and the mouse cursor happens to be in the same vertical axis as a numeric (number) text field with spinner (up and down buttons) but I'm not directly hovering on the field, there's a chance that the page will scroll and put the field under the mouse cursor, and immediately then, the numeric field spinner activates and changes the number in it. The page may continue to scroll beyond the spinner and if you notice, the number in the text field changes as the field passes under the mouse cursor.

Please see attached GIF for a demonstration.

HTML:
<input class="spinner" type="number">

CSS:
.spinner:hover::-webkit-inner-spin-button,
.spinner:hover::-webkit-outer-spin-button {
opacity: 1;
}

Actual results:

This unexpected behavior has always frustrated me as I would accidentally change my input in forms when I'm attempting to scroll the page up and down. My mistake is extremely difficult to detect and I may submit an erroneous input in the form without ever realizing it before submission. Some websites do not allow corrections to my submission, therefore I'm at risk of falsifying information unintentionally (imagine: an online tax form).

Expected results:

When using a mouse wheel or any other form of scrolling, the page scrolling action must never be combined with other actions like changing the numeric input using a spinner. I propose that when the page is scrolling, the mouse wheel must not activate any other behavior of any kind until the page has stopped scrolling and the user has moved the mouse cursor around to signal that there's no further intention to scroll the page.

To be honest, I've never ever found an use for using the mouse wheel to spin the number in the numeric text field - it's simply easier to type in the exact number I want. I wonder if anyone finds wheel-spinning inside the numeric text field to be an efficient input method. Therefore I also propose that the ability to use the mouse wheel to change the input of a spinner be fully removed from the browser, or otherwise deactivated by default in the fix release (to be activated again by those who need it through a config parameter). When wheel control is deactivated or removed, the spinner must only be usable through clicking up/down arrow control or by pressing up/down keys on keyboard.

For testing, the fiddle is available here: https://jsfiddle.net/z61fpbhw/

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

Hard to decide between this, "Layout: Form Controls" and "Layout: Scrolling and Overflow". I think this is the best fit, as the bug only occurs when the field is in keyboard focus (I clicked inside it) and it's passing under the mouse cursor (moving in and out of mouse focus). And it's an event in the GUI (at least I see it that way).

PS: The bot is wrong.

Component: Panning and Zooming → DOM: UI Events & Focus Handling
Component: DOM: UI Events & Focus Handling → DOM: Forms

Wow, great find Olli! Yep, there lies the problem.

Line 4004 - add an extra check for whether the page is actively scrolling or the delay between last active page scroll and the current wheel event is below a certain threshold (unless there's another way to distinguish the two). The code to increment or decrement must not execute if this check is true.

That's the simplest pseudo-code I can think of. But of course, it can be enhanced with user control through a configuration in about:config - though this may not be necessary if the problem is fixed with a more predictable behavior.

I'm more into Java and Web Development, so I can't write up the C++ code for this. Hope you can help :)

PS: The user configuration (if one is added) would be for controlling whether the mouse wheel changes the number/range in the focused numeric field or has no effect (scrolls the page instead). It's not meant to switch the reported erratic behavior on and off ;)

Regressed by: 1261674
Regressed by: 1261673
Has Regression Range: --- → yes
Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: