[mgradwohl]

Description

UiLayersOnDisplayTest.TitleBarDragStepSurvivesAFocusLossRightAfterThePress sometimes saw pressRetries == 0 under ctest's parallel load on windows-2025 debug.

Root cause (test timing, not a product bug): on the first press, the driver pushed SDL_EVENT_MOUSE_BUTTON_DOWN and then SDL_EVENT_WINDOW_FOCUS_LOST, with the test pointer already held at the drag's target (+40, +30). Core::Application's event drain stops once it has used DRAIN_BUDGET_MS (8 ms) and checks that after every event. Under load the drain could stop right after the press, so TitleBarLayer::onUpdate stepped the drag that frame and moved the window. The focus loss then ended a drag that had already done its job, the window counted as moved, and the retry never ran. #2925/#2935 aren't involved: this driver never moves the OS cursor and never warps.

Fix (harness only): with loseFocusAfterFirstPress, the driver

• holds the pointer still at the press point, so a drag step between the two events can't move the window;
• watches its own onSDLEvent, which runs after TitleBarLayer's, for the press and then the focus loss;
• moves the pointer to the drag target only once both have been handled, and starts the RETRY_EVERY wait from there.

After that, only a press made again can move the window, however the frames split the events. The test still asserts movedByDrag and pressRetries >= 1. It now also asserts focusLossDelivered and records pressRetries as a property.

The test proves as much as before. With TitleBarLayer temporarily changed to ignore SDL_EVENT_WINDOW_FOCUS_LOST, the new test fails (pressRetries 0), because the surviving drag moves the window with no retry.

Fixes #2901

PR Size

Small: 1 file, +65/-4 (test only).

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Build/CI improvement

Checklist

• I have read the CONTRIBUTING guidelines
• My code follows the project's coding standards
• I have run clang-tidy and addressed any warnings (nothing on the changed lines; the local LLVM reports only untouched lines and MSVC STL headers)
• I have run clang-format on my changes
• I have run pre-commit run --all-files or installed pre-commit hooks (pre-commit run --files on the touched file, plus the commit hook)
• I have added tests that prove my fix/feature works
• All new and existing tests pass
• I have updated documentation as needed (the driver's and the test's comments)

Testing

Windows 11, win-debug, TASKSMACK_REQUIRE_DISPLAY=1:

• Forced repro: with DRAIN_BUDGET_MS temporarily set to 0 (one event per frame, so the press and the focus loss always land in different frames), the old test failed 5/5 with CI's exact message (Expected: (observed.pressRetries) >= (1), actual: 0 vs 1). The new test passed 5/5 with the other two drag tests.
• Mutation check: with the real budget and TitleBarLayer's focus-loss handling turned off, the new test fails 3/3.
• Repeat: ctest --preset win-debug -R "^UiLayersOnDisplayTest$" --repeat until-fail:30 passed, 30/30 runs of the whole suite.
• Under load: 24 CPU burners (1.5x the 16 logical cores), bounded to 110 s, while both drag tests ran 25 times: 50/50 OK.
• Suites: UiLayersOnDisplayTest and UiScenarioTest once each: both passed.

cmake --build --preset win-debug --target TaskSmackAppTests -j 4
ctest --preset win-debug -R "^UiLayersOnDisplayTest$" --repeat until-fail:30
ctest --preset win-debug -R "^(UiLayersOnDisplayTest|UiScenarioTest)$"

Additional Notes

The drain budget itself is right: it caps how long a stalled poll can hold a frame (#1410). A real focus loss between the press and the first step ends the drag either way, so the product's behaviour doesn't change. Only the test's assumption that the two pushed events share a frame was wrong.

🤖 Generated with Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None