As part of the FLUID-4929 fix we introduced an event intrinsic to an IoC Testing framework fixture, "onTestCaseStart", which allows the timing of component construction to be "caught" by the beginning of a fixture sequence - the typical use of this is via a createOnEvent: "onTestCaseStart" directive. An implementation bug allows this event to fire twice for the same sequence if the listener to initial firing synchronously causes control to pass to the final element of the sequence. This event was implemented lazily using two firing sites and guarded by a flag whose setting was mistimed.

This arose during work on the preference editing framework - https://github.com/cindyli/prefsEditors/blob/GPII-1014/tests/adjusters/js/cursorSizePCPTests.js#L106-L107 held

sequence: [{
listener: "gpii.tests.cursorSizePCPTests.testDefault",
priority: "last",
event: "

{cursorSizePCPTests cursorSizePCP}

.events.afterRender"
}, {
func: "gpii.tests.cursorSizePCPTests.pressStepper",
args: ["

{cursorSizePCP}

"]
}]

where the corresponding environment was defined as

fluid.defaults("gpii.tests.cursorSizePCPTests", {
gradeNames: ["fluid.test.testEnvironment", "autoInit"],
components: {
cursorSizePCP: {
type: "gpii.adjuster.cursorSizePCP",
container: ".gpiic-cursorSizePCP",
createOnEvent: "

{cursorSizePCPTester}

.events.onTestCaseStart",

the framework passes via its "makeBinder" directly from the listener to sequence point 0 to point 1, triggering the re-construction of the "cursorSizePCP" component before its first construction has finished. There's probably a strong case for introducing asynchrony between all transitions in these test case fixtures, since the behaviour of the framework on re-initiating construction or destruction during either construction or destruction is undefined. These conditions should also receive explicit diagnostics - although these wouldn't have done a much better job in trapping and explaining the current issue than the one we already have.