-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure drag handlers request render frames on move #6068
Conversation
Closes #6063 Caused by #6005 because, after that change, the drag handlers relied on the `move` event to trigger a map rerender to pick up the next batch of mouse movements. This worked fine while dragging was in progress, but after the user paused and the render frame triggered by the last `move` event was complete, there was nothing to re-initiate the render loop once the mouse moved again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚡️ thanks for the quick fix + test coverage! 🏆
// https://github.com/mapbox/mapbox-gl-js/issues/6063 | ||
update.reset(); | ||
simulate.mousemove(map.getCanvas(), {bubbles: true, buttons: 2}); | ||
t.equal(update.callCount, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can do t.ok(update.calledOnce())
as well but this works too!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like t.equal(update.callCount, 1)
because if it fails, you see the actual/incorrect value in the test log
Sorry if it's a stupid question, but I wonder why it has been merged into |
We're using |
Closes #6063 Caused by #6005 because, after that change, the drag handlers relied on the `move` event to trigger a map rerender to pick up the next batch of mouse movements. This worked fine while dragging was in progress, but after the user paused and the render frame triggered by the last `move` event was complete, there was nothing to re-initiate the render loop once the mouse moved again.
…box#6073) Closes mapbox#6063 Caused by mapbox#6005 because, after that change, the drag handlers relied on the `move` event to trigger a map rerender to pick up the next batch of mouse movements. This worked fine while dragging was in progress, but after the user paused and the render frame triggered by the last `move` event was complete, there was nothing to re-initiate the render loop once the mouse moved again.
…box#6073) Closes mapbox#6063 Caused by mapbox#6005 because, after that change, the drag handlers relied on the `move` event to trigger a map rerender to pick up the next batch of mouse movements. This worked fine while dragging was in progress, but after the user paused and the render frame triggered by the last `move` event was complete, there was nothing to re-initiate the render loop once the mouse moved again.
Closes #6063
Caused by #6005 because, after that change, the drag handlers relied on the
move
event to trigger a map rerender to pick up the next batch of mouse movements.This worked fine while dragging was in progress, but after the user paused and the render frame triggered by the last
move
event was complete, there was nothing to re-initiate the render loop once the mouse moved again.Launch Checklist