text_selection: Fix flaky drag tests inside dialogs and sheets

[ihavecoke]

Summary

drag_inside_dialog_still_selects_its_text failed once on macOS CI with dialog text was not selectable: "". Text selection itself is fine. The test setup races the Dialog's entrance animation: the animation runs on wall-clock time, and the test drags at bounds captured while the Dialog is still sliding in. setup_modal now reduces motion so the animation settles on its first frame.

Why it fails

The test opens a Dialog, calls settle(), reads the TextView bounds, then drags across them.

1. settle() calls advance_clock(500ms) to get past the 250ms entrance animation (ANIMATION_DURATION). That only advances the test scheduler's clock. GPUI's with_animation measures elapsed time with scheduler::Instant, which is web_time::Instant, the real clock on native targets. So when the bounds are read, the animation has barely started.
2. The slide-down animation moves the Dialog from the window top down to margin_top (a tenth of the window height). Its easing, cubic_bezier(1/3, 0.72, 2/3, 1), moves fastest in the first frames.
3. drag() redraws after the mouse down and after each move. If enough real time passes between the bounds read and those redraws, the Dialog has moved down, the drag points computed from the old bounds no longer sit on the text, and nothing is selected.

When it fails

Normally the bounds read and the drag are microseconds apart (the whole gpui-component lib suite ran 618 tests in 1.76s in the failing job), so the Dialog barely moves. The test fails only when its thread stalls for about 28ms or more at exactly that point.

Measured locally without this fix, sleeping N ms between the bounds read and the drag, 5 runs per delay:

Delay	Passed
0–25ms	5/5
28ms	2/5
30ms	1/5
33ms and above	0/5

With this fix, 20ms and 100ms delays pass every run.

On the macOS runners cargo test runs tests on one thread per core, so hundreds of GPUI tests share a few vCPUs and a test thread can be descheduled for tens of milliseconds. The stall has to hit this short window, which is why the failure is rare.

Previous CI failure

• CI run 36437182105, attempt 1: Test (aarch64-apple-darwin, macos-latest) on website: Fit StatusBar demo sections to narrow windows #3301 at cc2ab056, which only changes a story file. 617 passed, 1 failed. Attempt 2 on the same commit passed.
• No other occurrence in the history checked: none of the 80 CI runs that ended in failure since 2026-09-09 failed on this test, and among the 199 CI runs since 2026-09-25 this is the only one that was retried.

Fix

setup_modal calls cx.set_reduce_motion(true), as the Dialog tests in dialog.rs and crates/kit/tests/root.rs already do. With reduced motion a oneshot animation renders its final frame immediately, so the bounds the test reads are where the Dialog stays.

The helper is shared by the five tests that open a Dialog or Sheet:

• drag_inside_dialog_still_selects_its_text
• drag_inside_sheet_still_selects_its_text
• opening_dialog_clears_base_selection
• selection_behind_active_dialog_is_excluded
• selection_behind_active_sheet_is_excluded

Test-only change; no production code or public API is affected.

Context

Branch: ihavecoke/fix-flaky-modal-selection-tests

The change was written with AI assistance.

Generated with Claude Code