RESOLVED FIXED 244240
Mouse wheel behavior on <input type="number"> is changed by other elements with wheel event handler 
https://bugs.webkit.org/show_bug.cgi?id=244240
Summary Mouse wheel behavior on <input type="number"> is changed by other elements wi...
azuma.ginkakuji
Reported 2022-08-23 00:57:02 PDT
Steps to reproduce problem 1. Open https://jsfiddle.net/ytfh4r2k/ 2. Focus the first input field and move mouse pointer on it. 3. Turn the mouse wheel on the first input field. 4. Then, focus the second input field and move mouse pointer on it. 5. Turn the mouse wheel on the second input field. Actual: Each input field behaves differently: the value of the first input field changes but the value of the second input field doesn't change. Expected: Both input fields behave in the same way. I think it is strange that the wheel behavior changes by an event handler of not-self nor not-ancestor elements. It behaves as expected in Firefox. Chrome behaves as the same as Safari. https://bugs.chromium.org/p/chromium/issues/detail?id=1355750
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2022-08-23 10:34:52 PDT
Reproduces with trackpad too. Also reproduces in Chrome. This is strange indeed, TextFieldInputType::shouldSpinButtonRespondToWheelEvents() is a very simple function. I think that this isn't even a DOM issue, but we probably short circuit these wheel events in UI process. Both input fields respect wheel/scroll events in WebKit1, and the bug only reproduces with WebKit2. It's curious that Chrome appears to have an identical one.
Radar WebKit Bug Importer
Comment 2 2022-08-30 00:57:16 PDT
<rdar://problem/99318505>
Simon Fraser (smfr)
Comment 3 2022-09-08 16:43:34 PDT
This is happening because the <p> with the wheel event handler is creating an event region, so we send wheel events to the main thread. What we should be doing is to add <input type="number"> to the wheel event region, like we do for <select>
yisibl
Comment 4 2024-11-26 23:15:32 PST
This case also reproduces the problem. ```html data:text/html;charset=UTF-8,<!DOCTYPE html><input type="number" value="1" onwheel="" /> ```
Daniel Holbert
Comment 5 2024-12-30 17:04:38 PST
(In reply to Simon Fraser (smfr) from comment #3) > What we should be doing is to add <input type="number"> to the wheel event > region, like we do for <select> You might not actually want to do that; I think that's what Firefox was doing, but it resulted in number-input-fields being unintentionally mutated. Screencast to demonstrate that: https://bugzilla.mozilla.org/attachment.cgi?id=9252014 I switched off our implementation of this wheel-mutation-behavior entirely in https://bugzilla.mozilla.org/show_bug.cgi?id=1741469 as a result of that footgun. We now have https://bugzilla.mozilla.org/show_bug.cgi?id=1939377 filed to consider reenabling it with some sort of opt-in mechanism (possibly checking for `wheel` event-listener as Chrome/Safari do now, perhaps unintentionally).
Simon Fraser (smfr)
Comment 6 2025-01-06 10:57:49 PST
Thanks for the heads-up!
Daniel Holbert
Comment 7 2025-01-06 16:03:44 PST
(In reply to Daniel Holbert from comment #5) > (In reply to Simon Fraser (smfr) from comment #3) > > What we should be doing is to add <input type="number"> to the wheel event > > region, like we do for <select> > > You might not actually want to do that; I think that's what Firefox was > doing, but it resulted in number-input-fields being unintentionally mutated. > Screencast to demonstrate that: > https://bugzilla.mozilla.org/attachment.cgi?id=9252014 Sorry, that^ screencast wasn't super-great at illustrating the problem. Here's a better one: https://bug1741469.bmoattachments.org/attachment.cgi?id=9445963 (This is using this testcase: https://bug1741469.bmoattachments.org/attachment.cgi?id=9445961 , with the wheel-mutation-behavior toggled back on as shown at the start of the screencast.)
Daniel Holbert
Comment 8 2025-01-14 15:21:35 PST
Historical note -- this may have been a regression in WebKit at some point. Safari 5.1 matches the permissive behavior that Firefox recently had -- i.e. focused number fields were mutable via mousewheel scrolling, without any special event listener needed. I confirmed that using this testcase: ``` data:text/html,<input type="number" value="0"> ``` I can mousewheel-scroll to change the value in that testcase (after focusing the field), using BrowserStack to test Safari 5.1 on Snow Leopard, and Safari 5.1 & 6.0.5 on Lion. However, Safari 6.2 on Mountain Lion and 7.1 on Mavericks both behave like current Safari, where they need the `wheel` event-listener in order for the number field to be mutated.
Daniel Holbert
Comment 9 2025-01-14 15:42:59 PST
See also https://github.com/whatwg/html/issues/10911 where we're suggesting that this opt-in mechanism be standardized in some way, possibly using a `wheel` event listener for backwards-compatibility with the behavior that Chrome & Safari are currently shipping (which some sites have come to rely on).
Anne van Kesteren
Comment 10 2025-01-22 08:16:45 PST
Pull request: https://github.com/WebKit/WebKit/pull/39382
Anne van Kesteren
Comment 11 2025-01-22 08:17:28 PST
Given the feedback on the HTML issue and the fact that this doesn't actually match Apple platforms I have put up a patch to remove this functionality completely.
EWS
Comment 12 2025-01-23 05:51:08 PST
Committed 289285@main (03828826a1c3): <https://commits.webkit.org/289285@main> Reviewed commits have been landed. Closing PR #39382 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.