Scroll wheel zooms several layers when Windows setting "scroll multiple lines at a time" enabled

[tstibbs]

Checklist

• I've looked at the documentation to make sure the behavior isn't documented and expected.
• I'm sure this is an issue with Leaflet, not with my app or other dependencies (Angular, Cordova, React, etc.).
• I've searched through the current issues to make sure this hasn't been reported yet.
• I agree to follow the Code of Conduct that this project adheres to.

Steps to reproduce

1. Set the Windows setting Roll the mouse wheel to scroll to Multiple lines at a time and the slider to 6 or greater (on my system at least, the exact number may possibly vary between configurations).
2. Use the mousewheel to zoom leaflet in or out.

Expected behavior

Rolling the mouse wheel one 'click' would cause leaflet to zoom in or out by one layer zoom level.

Current behavior

Rolling the mouse wheel one 'click' causes leaflet to zoom multiple layers zoom levels in one go.

Minimal example reproducing the issue

https://codepen.io/tstibbs/pen/zYawxGP

Environment

• Leaflet version: 1.9.2
• Browser (with version): Chrome 107.0.5304.89 (64-bit)
• OS/Platform (with version): Windows 10, mix of different screen resolutions with mix of different Windows text zoom settings in.

Why is this a problem?

I would personally expect a single 'click' of the mousewheel to correspond to zooming a single layer zoom level. There is the option wheelPxPerZoomLevel but it's difficult to set that appropriately because you don't know what your users will have set the "Multiple lines at a time" setting to.

Fundamentally, just because someone has chosen to scroll multiple lines of their document/webpage/terminal/etc, does that really mean they want to zoom multiple layers zoom levels on their map? If layers zoom levels were very granular (and you had hundreds of layers zoom levels) then it might make more sense, but even with fully vector maps like OSM you rarely see it being presented with more than 20 layers zoom levels so there really isn't the need to be able to scroll that quickly.

For me personally, I have been using a particular leaflet-based map on a regular basis for a few years and only today realized that I was skipping layers zoom levels when I scrolled - so regardless of what we say about configuration and user choices, the current set up means that many users will be missing layers without realizing. I suspect multi-line scrolling is the default in Windows (I don't recall configuring it) so many users will experience this problem by default.

Notes

Previous issues related to multiple-layerzoom-level scrolling: #8125, #4538, #7403, #7477, #8298

I'm aware that there are issues around trackpads, magic mice and also fractional layer zoom level zooming that are going to make this problem far more complex than we'd like it to be.

Some debug info captured while investigating

wheelPxFactor: 2
wheelPxPerZoomLevel: 60

Windows scroll lines:	5	6	8
e.deltaY in map/handler/Map.ScrollWheelZoom.js:45 (_onWheelScroll)	-166.66665649414062	-200	-266.6666564941406
resulting delta in map/handler/Map.ScrollWheelZoom.js:75 (_performZoom)	1	2	2
result	😄	😢	😢

[IvanSanchez]

I would personally expect a single 'click' of the mousewheel to correspond to zooming a single layer. There is the option wheelPxPerZoomLevel but it's difficult to set that appropriately because you don't know what your users will have set the "Multiple lines at a time" setting to.

You've done a great deal of investigation for this bug report (which is appreciated!), and you've hit the reason why this is difficult. It's impossible for the Leaflet code to know whether a wheel event comes from a scrollwheel or a trackpad (or touchscreen, or whatever) - and AFAIK it's not possible to know any value derived from the "scroll lines" setting.

I even seem to recall that it's possible some mice clicky scrollwheels fire events with souble or triple the delta whenever they're being scrolled too quickly (several events during a single browser animation frame). Maybe I'm imagining this, but it's a feasible scenario.

I'd like to implement #4696 at some point - should help with this.

The only solution that I see right now is clamping the delta to +/-1, but I'm afraid that might break something else.