Not sure if this would be considered a bug, but there may be some inconsistent behaviour with
attachElement functions, depending on the order they are called in.
// Example 1
// This will invoke someInput.attachControl(someNoPreventDefaultValue)
// Example 2
// This will invoke someInput.attachControl(), without using someNoPreventDefaultValue or the saved CameraInputsManager.noPreventDefault value
Should the following line in the codebase be using
Just bumping cc @PolygonalSun
Hey @carolhmj, thanks for the bump! Sorry about missing this, I’ll take a look at it and see what I can find.
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 before
attachElement 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.