Scroll zoom does not zoom out as much as zoom buttons in navigation controls
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 12.4k
- Forks
- 2.4k
- PR merge metrics
- No merged PRs in 30d
Description
Hello! I've noticed this inconsistency in behavior/zooming in my own code but also in an example provided in the Mapbox GL JS documentation (linked below), which is an indicator that it wasn't my code causing this issue.
Essentially, when using scroll zoom, it seems to have a higher minimum zoom (level 0 seems to be the farthest scroll zoom can go) than the zoom buttons in the navigation controls (which seem to allow zoom below 0 into the negatives depending on map size). This behavior is more obvious the smaller the map and can be further observed by adding a console log of the zoom level in a zoom event listener.
**mapbox-gl-js version**: v2.7.0
**browser**: Chrome
### Steps to Trigger Behavior
1. Zoom out all the way using zoom out button in navigation controls.
2. Use trackpad or mouse wheel to scroll down/out on the map.
### Link to Demonstration
https://docs.mapbox.com/mapbox-gl-js/example/navigation/
I've taken out my access token, but here is the example in codepen.
https://codepen.io/fang-zhi/pen/eYyVZaX
### Expected Behavior
The map would not change its zoom since it is all the way zoomed out. I would also expect scroll zoom to be able to zoom out as far as the navigation buttons can.
### Actual Behavior
The map "snaps" in when using the trackpad to scroll down/out after zooming all the way out using the buttons. Scroll zoom also cannot zoom out as much as the navigation buttons.
Video of behavior:
At the start of the video, I'm using the scroll wheel on my mouse to zoom out as far as the map allows. Then you can see that the map can actually zoom out further using the button. Then I use my mouse wheel to zoom out more, but the map snaps in instead of staying at the same zoom level since it is all the way zoomed out already.
https://user-images.githubusercontent.com/97124012/161771819-dc93e8dd-cb9c-4dfe-a5aa-9d8765737d42.mov
This recording shows the same behavior with the zoom levels printed out in the console.
https://user-images.githubusercontent.com/97124012/161771839-a2b47a17-f358-4f79-83bc-20e1695c19bb.mov
I understand that the default minZoom is level 0 if it has not been specifically set in the Map constructor parameters. Reading through this repo, however, it seems that the map can zoom out up to -2 (although may never reach this point depending on the size of the container). This is also confirmed with a console log in a zoom event listener. Setting the minZoom to -2 in the map constructor does not resolve this inconsistency in zooming when using gestures vs buttons.
This is mostly a concern when the map is quite small as the discrepancy is more obvious. In my application, the container the map is in can be resized by the user as big or small as they like and I'd like for users to be able to zoom out to the same level as the buttons while using scroll zoom, but it doesn't seem to be the current behavior. I've worked around this with a separate wheel event handler for now, but I'd like to know if this actually a bug or if it was intentional. If it was intentional, I'd like to know the reason and if there are any drawbacks to allowing scroll zoom to zoom beyond zoom level 0. Thank you!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the behavior in the linked navigation example and CodePen using the described button-then-scroll steps. Start by comparing the scroll-zoom and navigation-control paths for their minimum zoom handling; done means both interactions stop at the same zoom level without snapping inward, with the behavior verified at small map sizes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100