Attach camera-controls pointermove event listeners to window instead of element

Discussed in https://github.com/google/model-viewer/discussions/2678

<div type='discussions-op-text'>

^{Originally posted by lucadalli August 10, 2021} When rotating a model with camera-controls enabled, I often find myself getting frustrated at the model’s unresponsiveness when my pointer falls out of the element’s bounds.

When I’m interacting with the model, after the initial pointerdown event, I become far less conscious of where my pointer is and more focused on the actual orientation of the model. I’d be rotating the model, until suddenly, my inputs are no longer recognized, only for me to realize that my pointer is outside the element. This breaks my “immersion” as I have to reset my pointer position back onto the model and resume the interaction.

I strongly believe this is an inferior user experience to the one offered by THREE’s OrbitControls, which attaches move listeners to window and hence allows an initiated camera interaction to continue anywhere on the page until the pointer is released.

https://threejs.org/examples/#misc_controls_orbit

</div>

[lucadalli]

Great, I have also tested Android Edge and it behaves like the rest. Given that all modern mobile browser are consistent, the way we handle touch events can remain as is. I will address mouse events, which should be a trivial change.

As you work on this, please keep this example in mind, as we want to make sure it is still easy for users to customize their UX by intercepting events before they get to us. We need to be mindful of anything that may be a breaking change.

Noted. I’ll verify that changes are backwards compatible.

[elalish]

Yes, I have those devices locally; let me get back here with results.