244240 2022-08-23 00:57:02 -0700 Mouse wheel behavior on <input type="number"> is changed by other elements with wheel event handler 2025-01-23 05:51:11 -0800 1 1 1 Unclassified WebKit WebKit2 Safari 15 Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=42441 InRadar P2 Normal --- 1 azuma.ginkakuji annevk 50167214 akeerthi annevk azuma.ginkakuji cdumez dholbert karlcow kkinnunen ntim rniwa simon.fraser webkit-bug-importer wenson_hsieh oldest_to_newest 1893183 0 azuma.ginkakuji 2022-08-23 00:57:02 -0700 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 1893269 1 ap 2022-08-23 10:34:52 -0700 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. 1894734 2 webkit-bug-importer 2022-08-30 00:57:16 -0700 <rdar://problem/99318505> 1897143 3 simon.fraser 2022-09-08 16:43:34 -0700 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> 2077832 4 50167214 2024-11-26 23:15:32 -0800 This case also reproduces the problem. ```html data:text/html;charset=UTF-8,<!DOCTYPE html><input type="number" value="1" onwheel="" /> ``` 2084303 5 dholbert 2024-12-30 17:04:38 -0800 (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). 2085113 6 simon.fraser 2025-01-06 10:57:49 -0800 Thanks for the heads-up! 2085252 7 dholbert 2025-01-06 16:03:44 -0800 (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.) 2087250 8 dholbert 2025-01-14 15:21:35 -0800 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. 2087257 9 dholbert 2025-01-14 15:42:59 -0800 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). 2088988 10 annevk 2025-01-22 08:16:45 -0800 Pull request: https://github.com/WebKit/WebKit/pull/39382 2088989 11 annevk 2025-01-22 08:17:28 -0800 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. 2089250 12 ews-feeder 2025-01-23 05:51:08 -0800 Committed 289285@main (03828826a1c3): <https://commits.webkit.org/289285@main> Reviewed commits have been landed. Closing PR #39382 and removing active labels.