Skip to content
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

Mouse/pointer not captured when dragging out of the canvas area on web target #1660

Closed
alvinhochun opened this issue Aug 18, 2020 · 4 comments · Fixed by #1672
Closed

Mouse/pointer not captured when dragging out of the canvas area on web target #1660

alvinhochun opened this issue Aug 18, 2020 · 4 comments · Fixed by #1672
Labels
B - bug Dang, that shouldn't have happened C - in progress Implementation is proceeding smoothly DS - web

Comments

@alvinhochun
Copy link
Contributor

When dragging from inside the canvas to outside, the winit window stops receiving mouse events.

Possible fixes:

  • When PointerEvent is available, one can use canvas.setPointerCapture on pointerdown to capture the pointer.
  • When using the MouseEvent fallback, the mouse* events should be attached to the window and the event handling code has to manually track the mouse capturing state. There is an implementation in kiss3d (web-sys version that can serve as an example.
@ryanisaacg
Copy link
Contributor

Is there a reason the canvas should continue to receive mouse events once the mouse leaves the area?

@ryanisaacg ryanisaacg added DS - web C - needs discussion Direction must be ironed out B - bug Dang, that shouldn't have happened labels Aug 18, 2020
@alvinhochun
Copy link
Contributor Author

alvinhochun commented Aug 19, 2020

Is there a reason the canvas should continue to receive mouse events once the mouse leaves the area?

  • The window currently does not receive a mouse release event if the mouse is released outside of the canvas, causing the user code to think that the mouse button is stuck.
  • This mouse capturing behaviour is beneficial for drag operations like adjusting up/down spinners or performing camera movements due to the increased movement area (though one might argue that using the pointer lock API is more suitable for the task).
  • It should for consistency because this is how it behaves on native targets.

@alvinhochun
Copy link
Contributor Author

Do you have any concerns with fixing this?

@ryanisaacg
Copy link
Contributor

Nope, if it's the behavior on native targets then I'm all for it.

@ryanisaacg ryanisaacg added C - in progress Implementation is proceeding smoothly and removed C - needs discussion Direction must be ironed out labels Aug 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened C - in progress Implementation is proceeding smoothly DS - web
Development

Successfully merging a pull request may close this issue.

2 participants