Fixing BC OnEnable issue when non-default activation type specified in-editor

[Zee2]

Overview

A regression was introduced in a previous BoundsControl fix that impacted activation behavior when a non-default activation type was specified in-editor. Behavior was correct when a BoundsControl was set up at runtime, as OnEnable would run with the default activation type, and any subsequent sets to BoundsControlActivationType would properly evaluate the activation policy. The regression only impacted scenarios when a non-default activation type was specified in-editor, and OnEnable ran with that activation type.

As a result, this is technically a symptom of missing test coverage. However, this bug is only visible when an option is specified in edit-mode, and then the scene is played. As we can't really write tests that cover a transition from edit to play mode, @CDiaz-MS confirmed that this should be alright to merge without a specific test. This issue can be smoked out by running the BoundsControlExamples example scene and checking that the BCs do not activate when they're not supposed to.

Root cause: the order of CreateRig and SetActivationFlags had been swapped in a previous fix, as SetActivationFlags requires the TargetBounds to be set in order to be able to determine the flattening result. CreateRig was moved to be called before SetActivationFlags, so that DetermineTargetBounds would be called before SetActivationFlags needed the TargetBounds. However, this introduced a regression wherein CreateRig would not respect a non-default activation type if specified in-editor, as it was not calculated yet. The fix is to revert to the prior ordering of CreateRig and SetActivationFlags, but introduce a preemptive call to DetermineTargetBounds, to make sure TargetBounds has been initialized before any other functions need it.

Changes

• Reverts the initialization order of CreateRig and SetActivationFlags to a prior version
• Adds a pre-emptive call to DetermineTargetBounds to resolve target bounds before any other functions need it

Verification

As specified above, a test to cover this behavior is not practically implementable. Verification can be done by smoke testing the BoundsControlExamples scene.

[Zee2]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).