Do not misclassify late graph-handle observation as initially enabled controls

[mohidmakhdoomi]

Summary

The pointer-enable-delay E2E test requires its first graph snapshot to report controlsEnabled === false. Under high software-rendering contention, the graph handle may not become observable until after the valid four-second enable timer has already elapsed. The test then labels a late observation as “navigation controls should start disabled,” even though it did not observe the initial state at all.

This is a standalone temporal-observability issue. It should be fixed without reducing workers, bypassing SwiftShader, adding retries, or treating a later first observation as proof of incorrect initial state.

Reproduced trace sequence

During E2E_WORKERS=22 npm run test:smoke in Firefox:

• root navigation completed at approximately 9.008 s trace time;
• graph-handle probes initially returned no handle;
• later probe evaluations individually took several seconds under contention;
• the first successful graph-handle observation completed at approximately 19.209 s;
• that was roughly 10.2 seconds after navigation, well beyond the configured 4,000 ms enable delay;
• the snapshot correctly reported enabled controls, but the test failed because it required the first observation to be disabled.

The failure therefore does not establish that controls started enabled. It establishes only that the harness could not observe the component inside the inert window.

Required contract split

Two different contracts need independent evidence:

1. Initialization/scheduling contract

   • interaction state initializes to disabled;
   • the enable callback is scheduled with the configured delay.

2. Browser behavior contract

   • enablement is not observed before a race-free lower bound from navigation;
   • controls eventually enable;
   • real pointer input works after enablement.

Unit/component coverage can deterministically protect the first contract. E2E coverage should protect the second without claiming that a late first snapshot represents initial state.

Proposed direction

• Keep an anchor captured before navigation, which necessarily precedes component mount and timer scheduling.
• Reach the graph handle as early as the renderer permits, but do not require that observation to occur within the delay window.
• Poll for eventual enablement; if the first snapshot is already enabled, treat that as the earliest observable enabled state.
• Assert that observed enablement is no earlier than the configured lower-bound floor.
• Separately lock the initial disabled state and configured scheduling call in deterministic unit/component tests.
• Continue exercising real wheel input immediately after observed enablement.

Acceptance criteria

• A first graph-handle observation after the configured delay is not described as proof that controls started enabled.
• Deterministic coverage asserts the initial interaction state is disabled.
• Deterministic coverage asserts the configured enable delay is used.
• E2E coverage rejects genuinely premature observable enablement.
• E2E coverage proves eventual enablement and working real pointer input.
• The test passes repeatedly under high SwiftShader contention without retries or worker reduction.