Glitchy behavior when animating fitBounds multiple times
See original GitHub issueTriggering code:
map.fitBounds([[-20, -20], [20, 20]]);
map.fitBounds([[-10, -10], [10, 10]]);
Expected behaviour: final state of the map reflects the last call to fitBounds
.
Observed behaviour: final state of the map might reflect either of the fitBounds
calls, depending on the initial map state.
The effect is reproducible as long as the second fitBounds
is called before the first has finished animating, eg:
map.fitBounds([[-20, -20], [20, 20]]);
setTimeout(function() {
map.fitBounds([[-10, -10], [10, 10]]);
}, 200);
or a user clicking two buttons in quick succession will also show the effect.
Disabling animation on the fitBounds
calls prevents the issue, but… the zooms are so pretty! 😃
I don’t have a simple testcase for it, but in my project, two quick fitBounds
calls can also leave the map in weirder states (zoomed out very far) that don’t reflect any of the fitBounds
calls.
Edit: the issue may not affect other animated view changes. tested and working as expected:
Issue Analytics
- State:
- Created 9 years ago
- Reactions:7
- Comments:23 (13 by maintainers)
Top GitHub Comments
Is the core issue here that Leaflet doesn’t cancel previous animations when a new one is triggered? I’ve noticed a situation I think is related, where I am updating the map bounds as several layers each asynchronously load.
Basically something like:
Admittedly a little weird logic (and even more complicated in practice…), but regardless, what I’m seeing is that by default I don’t always get the expected boundaries once both layers have loaded. That is, the map should always be zoomed to the
layer1
state once both layers load. But if layer2 happens to load first I do not get that result.If I avoid the default by adding
{animate:false}
to both calls then it does work as expected!So without diving into the Leaflet code, my theory is that if the
map.fitBounds(layer2.getBounds())
animation is still in progress when I requestmap.setView(layer1.getBounds().getCenter(), 12)
the earlier animation keeps progressing too, in parallel with and throwing off the end result of the new animation, perhaps?The original issue is still reproducible in @theashyster’s playground example. I think my explanation here is still a valid description of why this happens, but we need to figure out how.