Replies: 1 comment 4 replies
-
That all sounds fairly reasonable to me, though obviously we'll need to do some code review and lots of testing. Regarding pointer events, you should look over an old attempt I made: #1645. I was blocked by non-standard iOS Safari behavior I couldn't find a work around for. I suppose it's possible your other changes here might help avoid that bug, but it's hard to say. Especially if you don't have an iOS device for local testing, I'd stay away from pointer events for now. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What is the sentiment towards moving away from the checks on
event.type
andtouchMode
inonPointerMove
and instead attaching the correct switch subroutine directly as amousemove
/touchmove
handler depending onpointerdown
event type (mousedown
ortouchdown
) and the number of touches?This would roughly equate to the
mousedown
handler attaching themousemove
handler withhandleSinglePointerMove
and amouseup
handler which detaches themousemove
handler and themouseup
handler itself.For touch events, the
pointermove
event handler is determined every time a pointer is added or removed. So instead oftouchMode
, the manipulated variable is a new one namedtouchmoveHandler
which is assigned the currently activetouchmove
event listener so that it can be detached when!touches.length
or if the element is removed from the DOM mid-interaction.An added benefit of this approach is that the
mouseup
andtouchend
listeners are not added prematurely. Currently, these handlers are added as soon as controls are enabled, meaning that they sometimes fire for events which are unrelated to a model-viewer.With the proposed approach the only two persistent handlers would be
touchstart
andmousedown
on the model-viewer element. The rest are attached and detached in those two on the fly.Is the current implementation done this way to facilitate a migration to pointer events down the line?
Considering that the code is peppered with checks about the pointer type, would it be favorable to migrate to pointer events?
Beta Was this translation helpful? Give feedback.
All reactions