fix(apple): avoid blocked interactions on physical iOS#1263
Conversation
6ee5113 to
5d0b951
Compare
|
Review concern on exact head 5d0b951. The intended system-modal path is supported by the physical-device evidence, but coordinate-only taps now bypass target-app activation before checking hasCachedTargetForActivationSkip. That broadens the behavior beyond the reported foreground-app recovery case: when the requested app is not cached or no longer foreground and no blocking SpringBoard modal is detected, resolveAppWithoutActivation can return an unactivated XCUIApplication and the coordinate gesture may execute against the wrong visible surface. Please retain the cached-target and foreground guard for the ordinary no-modal coordinate path, while keeping the explicit SpringBoard-modal route able to bypass it. Add contrasts proving:
CI smoke and Swift jobs are also still pending, so this head is not merge-ready yet. |
5d0b951 to
8f9102a
Compare
Summary
alertcommands so system prompt inspection/dismissal can run while SpringBoard owns a blocking modalalertand coordinate-only taps to SpringBoard only when a blocking iOS system modal is visibleXCUIApplication.activate()when a newly created runner process resolves a target that is already foregroundWhy
A physical-iPhone permission dialog can be owned by SpringBoard while covering the target app. The runner previously accepted public coordinate tap commands, but prepared them by activating the target app first. XCTest can hang or abort in that activation/quiescence step while the SpringBoard modal is visible, so the command never reaches gesture synthesis. Screenshots still work because they do not need target-app activation.
The coordinate-only fast path is intentionally limited to an already foreground cached target. That preserves the existing activation safety net for ordinary no-modal commands, while the explicit SpringBoard-modal route can still bypass target-app activation when a native modal is actually blocking interaction.
There is a second form of the same activation failure. A fresh XCTest process has no cached bundle ID, so command preparation takes the
bundle_changedpath even when the requested app is already foreground. Callingactivate()in that state can wait indefinitely for a continuously updating React Native app to become idle. Reading the app state first and skipping only the redundant foreground activation preserves normal launch/background recovery while allowing the command to reach gesture delivery.Verification
origin/main(6efe54451)git diff --checkpnpm format:checkpnpm typecheckpnpm test(438 files, 4,041 tests)pnpm build:xcuitest:iosalert getdetected a native notification prompt and its buttonsalert dismisscleared the promptalert getwith no prompt returnedalert not foundpromptly instead of timing outmain thread execution timed outafterAGENT_DEVICE_RUNNER_ACTIVATE ... reason=bundle_changedwhile Dibs was already foregroundAGENT_DEVICE_RUNNER_ACTIVATE_SKIPPED ... reason=already_foregroundandCOMMAND_COMPLETED ... ok=1Remaining note
Accessibility snapshots can still time out later while traversing a continuously updating React Native view. That is separate from the pre-delivery activation failures fixed here; screenshots and coordinate taps remain the practical fallback when AX traversal itself cannot settle.
Refs #1246