-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Provide access mouse/touch events in continuously-updating interaction handlers #6047
Comments
One tricky thing to note is that this property was often used for things like |
Shoot, good point @mourner. We will need to provide a new way to do that |
originalEvent
property on movement events fired by continuously-updating interaction handlers
Initial ideas for how we can expose a way for users to
|
I suppose for 2, we could also re-emit the event under its same name ( |
Any concrete examples of this? I like to have a firmer idea how widespread/essential this is. |
My thinking is that we shouldn't try to fix this, and in fact, secondary map events like The use case of preventing default map handler behavior should be covered by #3290. If there are any other use cases, they should be handled by binding native DOM event handlers and stopping propagation of the DOM event before it even reaches the map code, either by using |
Studio uses |
Thanks to @stepankuzmin to calling my attention to one important use of This case could instead be addressed by reversing the check -- looking for a property that's added to programmatically triggered events with the |
Yeah, good point. Maybe something like a |
As a consequence of integrating camera easing into the main render loop (#5743), we've changed (#6005 #6029) the way continuously-updating interaction handlers manage the camera so that, during dragging/scrolling action, we accumulate movement from multiple mouse events between one render frame and the next, and then in each frame, we synchronously update the camera and fire
move
(androtate
, etc.) events.Right now, when
DragPanHandler
,DragRotateHandler
, andScrollZoomHandler
fire'move'
, etc., they attach the last mouse event asoriginalEvent
, even though multiple mouse events may be responsible for this particular'move'
. Instead, we should either (a) omitoriginalEvent
in these cases, or (b) include anoriginalEvents
array with all of the contributing events.The text was updated successfully, but these errors were encountered: