FlyControls: Introduce enabled property.

[andredsm]

Description

Recently, I came across a bug in FlyControls class. This class has a variable named "status" which controls whether the user is dragging the mouse/pointer. This variable is a counter, which is incremented on pointerDown event, and decremented on pointerUp event. On pointerMove event, the camera only rotates if this "status" variable is greater than 0 (when dragToLook is set to True).

In my application, I have an input form of file type. When the file dialog opens up, if it is above the threejs canvas, and the user selects any file by double-clicking, this dispatch only one pointerUp event to the FlyControls. As a consequence, the FlyControls remains in an invalid state, because the "status" variable is negative, and the user can never rotate the camera again.

I've seen similar issues with this missing pointer/mouse up event: example. This issue occurs in all majors browsers. So, to avoid this problem, I change this control variable to a boolean that only indicates whether the user is dragging the pointer or not. I can't see any reason for this variable to be a counter.

A JSFiddle example to reproduce the bug: just remind to reposition the file dialog over the canvas, in such a way the double click to the file is also over the canvas. After this, you are not allowed to rotate the camera.

[Mugen87]

Sorry for the late feedback!

I can confirm the invalid state of FlyControls in your fiddle however it seems there is an issue with this PR. Assume somebody is using two fingers to use the controls. When the user lifts one finger, the previous implementation would not stop the camera transformation. With this PR, dragging is stopped since the controls do not count the pointers anymore. So in some sense the PR fixes your issue but introduces a potentially unwanted change of behavior for someone else.

Would it be helpful to have controls.enabled similar to OrbitControls? With this you could disable FlyControls when the file input pops up and enable the controls again when a file has been selected.

[andredsm]

I agree with your comments and your suggestion. I haven't thought about the case of the user using a device with a touch screen, but indeed my current PR introduced this undesired behavior. Today later, I will update this PR to turn the manipulator on/off. Thank you for reviewing and suggestions.

[andredsm]

@Mugen87 I've just pushed the changes to meet your suggestions. Now I can control when to turn the camera manipulator on/off. I've also merged the dev branch onto my branch to keep it synced, and then I rebased my commits to make it linear (the reason for my forced-pushed commits). 🙃