fix PointerConstraints activation occurring before attached to InputManager

[bk304]

Describe your PR, what does it fix/add?

Fixes #8506

It is possible for the CInputManager::simulateMouseMovement() method to be called via CPointerConstraint::activate() without the constraint being present in InputManager.m_vConstraints.

This occurs when the constraint is activated before CPointerConstraintsProtocol::onNewConstraint is called, which is what places it in InputManager.m_vConstraints.

The lack of the instance of CPointerConstraint in m_vConstraints causes the CInputManager::isConstrained() method to fail and return false. As a result, the CInputManager::mouseMoveUnified method is run erroneously until it's end when the constraint is activated.

This does not seem to be very common behavior, but the FFXIV game running via wine and xwayland can trigger this.

As a solution, I found it ideal to postpone the activation of the constraint until after the onNewConstraint call.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

This change assumes that it is true that a constraint cannot be activated before it is bound to the Input Manager. I don't see any sense in which this could be wrong, but it would be good to have a sanity check.

Later I will test other games that restrict the mouse to see if anything obviously broke.

Is it ready for merging, or does it need work?

Ready for merging.

[vaxerski]

This occurs when the constraint is activated before CPointerConstraintsProtocol::onNewConstraint is called, which is what places it in InputManager.m_vConstraints.

how can a constraint send activate if it's not created yet?

[bk304]

This occurs when the constraint is activated before CPointerConstraintsProtocol::onNewConstraint is called, which is what places it in InputManager.m_vConstraints.

how can a constraint send activate if it's not created yet?

I just checked and it is the CPointerConstraint constructor that calls activate().

The activate() method expects the constraint to be ready, but this is not true during the execution of the constructor. It has not yet been added to the m_vConstraints of the Input Manager.

Perhaps, this activate() call could be moved from the constructor to onNewConstraint(). But I am unsure if this would not cause some problem.

[bubba-champion]

This MR fixes the issue I described in #7388

[bubba-champion]

However, this MR only partially resolves the issue. When switching to the workspace containing the game with a locked cursor, the problem still persists.

[bk304]

Perhaps, this activate() call could be moved from the constructor to onNewConstraint(). But I am unsure if this would not cause some problem.

It's okay to move it. It'll be much cleaner that way too.