This is all true of `<input type="range">` as well -- we adjust the form-control's value when it's focused & hovered, if the user does a mousewheel-scroll action, but Chrome does not (nor does Safari). So the same removal argument applies there, too -- this is a footgun if the user happens to try to scroll a page while hovering this type of form-field. Also notable: it appears Firefox does *not* change these form-fields' values for mousewheel-scroll events on MacOS -- only on Windows and Linux. I'm guessing that's because we observed (in bug 1261673 comment 19) that it was a Windows/Linux-specific feature in Chrome. (Though, as noted in my previous comment, I'm not seeing it on any platform in old or current Chrome at this point.)
Bug 1741469 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is all true of `<input type="range">` as well -- we adjust the form-control's value when it's focused & hovered, if the user does a mousewheel-scroll action, but Chrome does not (nor does Safari). So the same removal argument applies there, too -- this is a footgun if the user happens to try to scroll a page while hovering this type of form-field. Also notable: it appears Firefox does *not* change these form-fields' values for mousewheel-scroll events on MacOS -- only on Windows and Linux. I'm guessing that's because we observed (in bug 1261673 comment 19) that it was a Windows/Linux-specific feature in Chrome. (Though, as noted in my previous comment, I'm not actually seeing Chrome reproducing this behavior on *any* platform at this point.)