Not sure if this would be considered a bug, but there may be some inconsistent behaviour with CameraInputsManager’s add and attachElement functions, depending on the order they are called in.
For example:
// Example 1
CameraInputsManager.add(someInput);
CameraInputsManager.attachElement(someNoPreventDefaultValue);
// This will invoke someInput.attachControl(someNoPreventDefaultValue)
// Example 2
CameraInputsManager.attachElement(someNoPreventDefaultValue);
CameraInputsManager.add(someInput);
// This will invoke someInput.attachControl(), without using someNoPreventDefaultValue or the saved CameraInputsManager.noPreventDefault value
Should the following line in the codebase be using input.attachControl(this.noPreventDefault)?
So here’s what I’m seeing. What you’ve found is, in fact, an inconsistency in how it’s supposed to behave. It looks like any calls to attachControl won’t check for the current value of the camera’s noPreventDefault. In most cases, add should be called beforeattachElement as all default inputs are added in the constructor and attachElement is called when camera.attachControl is called. The scenario where this isn’t the case is if any new inputs are added (or removed and readded) after the controls are already attached. Your proposed fix looks like it should address this pretty easily. I can this change added as soon as I can get an opportunity.