iOS: re-press the Home tile context menu when hosted CI lands the long press as a tap (#100) #32

Merged

backmeupplz merged 2 commits from fix/100-context-menu-long-press into main

2026-10-13 07:54:41 +00:00

backmeupplz commented

2026-10-13 06:43:27 +00:00

(Migrated from github.com)

Fixes agentboard #100 (https://agentboard.icefish-betta.ts.net/#100).

Problem

On PR #24's CI, iOS (loading) failed in PlaybackPreparation.testHomeTileMetadataAndContextMenuCancelWhenLeavingHome: after continue.other was long-pressed for 1s, context.play.other never appeared. The failure's accessibility dump shows why: the tile was Disabled with its "Preparing…" overlay and the fixture readout said preparing: other. The hosted simulator delivered the long press as a plain tap, so the tile's own Button action started preparing instead of the context menu opening.

Change (tests only, `ios/UITests/PlaybackPreparation.swift`)

New contextMenu(_:_:undo:) helper long-presses the tile (2s instead of 1s) and waits up to gateTimeout for whichever the touch caused: the menu's Play item, or the readout showing preparing: <key>.
- Menu appeared: return.
- The press landed as a tap: run undo, which leaves Home for Library, asserts the cancel is terminal (releaseAndAssertNoPlayback), returns Home and re-holds the fixture, then presses again.
- Neither (press dropped outright): press again.
- Up to 3 presses; the test still fails if the menu never opens.
The test then taps the menu's Play, still requires preparing: other, leaves Home and asserts the cancel, exactly as before. Nothing it asserts was removed or loosened; the fallback adds an extra cancel assertion.

Validation

xcodebuild build-for-testing (generic iOS Simulator, arm64): succeeded.
Local simulator, -test-iterations 3 of the test: 3/3 passed.
Forced-recovery run (temporary local edit making the first press 0.1s, not committed): passed. The log shows the tap detected, Library → release → Current: none; preparing: none; playing: false asserted → Home → hold → 2s press → context.play.other → preparing: other → Library → cancel asserted.
CI: see checks on this PR (iOS (loading) runs the suite).

No runtime/app changes, no deployment required.

Fixes agentboard #100 (https://agentboard.icefish-betta.ts.net/#100). ## Problem On PR #24's CI, `iOS (loading)` failed in `PlaybackPreparation.testHomeTileMetadataAndContextMenuCancelWhenLeavingHome`: after `continue.other` was long-pressed for 1s, `context.play.other` never appeared. The failure's accessibility dump shows why: the tile was **Disabled with its "Preparing…" overlay** and the fixture readout said `preparing: other`. The hosted simulator delivered the long press as a plain tap, so the tile's own Button action started preparing instead of the context menu opening. ## Change (tests only, `ios/UITests/PlaybackPreparation.swift`) - New `contextMenu(_:_:undo:)` helper long-presses the tile (2s instead of 1s) and waits up to `gateTimeout` for whichever the touch caused: the menu's Play item, or the readout showing `preparing: <key>`. - Menu appeared: return. - The press landed as a tap: run `undo`, which leaves Home for Library, **asserts the cancel is terminal** (`releaseAndAssertNoPlayback`), returns Home and re-holds the fixture, then presses again. - Neither (press dropped outright): press again. - Up to 3 presses; the test still fails if the menu never opens. - The test then taps the menu's Play, still requires `preparing: other`, leaves Home and asserts the cancel, exactly as before. Nothing it asserts was removed or loosened; the fallback adds an extra cancel assertion. ## Validation - `xcodebuild build-for-testing` (generic iOS Simulator, arm64): succeeded. - Local simulator, `-test-iterations 3` of the test: 3/3 passed. - Forced-recovery run (temporary local edit making the first press 0.1s, not committed): passed. The log shows the tap detected, Library → release → `Current: none; preparing: none; playing: false` asserted → Home → hold → 2s press → `context.play.other` → `preparing: other` → Library → cancel asserted. - CI: see checks on this PR (iOS (loading) runs the suite). No runtime/app changes, no deployment required.