Lockup if using setView after adding a marker

[mdamien]

Related to #2236, the map lockup when calling setView after adding a marker

Demo: http://jsfiddle.net/e5YZ7/

[perliedman]

Seems to be the same bug.

I notice that panning the map with the mouse stops working as well, but if you pan the map using the keyboard, mouse panning works again.

[perliedman]

Another observation: putting a breakpoint at the first line of _tryAnimatedZoom in Map.ZoomAnimation.js makes the problem go away, which indicates some form of race condition. Also makes it a bit tougher to debug...

[perliedman]

Ok, trying some more things, here are even more observations:

• Putting the breakpoint in L.Marker._setPos (called by L.Marker._animateZoom) before the first call to L.DomUtil.setPosition removes the problem, putting anywhere after that makes the problem come back. My conclusion is that setting the position too fast is the problem.
• When the problem is there, _onZoomTransitionEnd is never called, which is why everything appears to block (since dragging is disabled), and the center and zoom isn't updated (since _resetView is never called)
• The problem goes away if I set L.Browser.any3d=false (changing how the position is set by L.DomUtil)

@mourner does this tell you anything? I'm out of ideas why using the 3d transform would prevent events from firing.

[perliedman]

_catchTransitionEnd in Map.ZoomAnimation.js is never reached, which I guess is the core problem. Reproducible in both Chrome 33 and Firefox 27 on Linux.

Sorry about spamming this issue with so many comments!

[mdamien]

Thanks for the feedback ! For the bug report, I included the wrong fiddle, here is mine ( a lot more compact): http://jsfiddle.net/tzRWp/1/

But, yeah, I think it's the same bug, so it doesn't matter. I hope it will help.

[perliedman]

I made a workaround for your latest fiddle: perliedman@e64545a

While I don't like fixing things with setTimeout 0, I really don't have any other clues right now - as mentioned above, the same result can be achieved by putting breakpoints in the right places, indicating that it isn't any Javascript that is executed in the wrong order, but rather some internal timing in the browser that needs to be correct.

I tried finding a similar approach for markers, but since they use L.DomUtil.setPosition for all positioning, it's not apparent to me how to do that in a way that doesn't alter the intended behaviour too much.

It appears that using transform3d "too soon", whatever that means, after the node has been added to the DOM causes the problem, but I might be missing something, since there are lots of moving parts involved, and I'm just starting to learn how they work together.

[GoTo-Romania]

similar bug here: #2485

[perliedman]

@GoTo-Romania yes, looks related.

[mourner]

@perliedman great research Per. To fix this for all layers, we could try modifying the zoom animation code to only start in the next frame (using Util.requestAnimFrame, probably better than setTimeout) — these lines specifically: https://github.com/Leaflet/Leaflet/blob/master/src/map/anim/Map.ZoomAnimation.js#L83-L88

[perliedman]

@mourner will try it out tonight, if you don't beat me to it!

[mourner]

We should also probably keep the frame id and cancel previous one before requesting to avoid any quirks of having multiple setView calls in a row.

[mourner]

Pushed a fix for this — please check on your test cases to verify it's OK.

[mdamien]

Wow! Thanks guys!