Repository navigation
fix: hand the foreground back after every broadcast start attempt (DRO-3369) - #40
Merged
Timo972 merged 1 commit intoOct 15, 2026
Conversation
The broadcast start restored the previously active app only on success. Every failure after the runner was brought forward (foregrounding timeout, picker error, confirmation tap error, extension connect timeout) left the runner's blank screen in front. The next attempt then found the runner already frontmost, had no app to restore, and never left it - even on success. That blank runner is what the screenshot fallback and a later broadcast capture, and on a phone lying on its side it rotates to landscape, so viewers see a black, sideways frame (DRO-3369). Restore on every exit path. When no previous app is known and the runner is still in front, activate SpringBoard instead (a HOME press does not reach SpringBoard on iOS 26). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
niko-droidrun
approved these changes
Oct 15, 2026
Timo972
deleted the
timo/dro-3369-wda-broadcast-rotates-by-device-orientation-not-ui
branch
October 15, 2026 09:53
Timo972
changed the title
Timo972
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
performBroadcastStartWithTimeoutrestored the previously active app only on success. Every failure after the runner was brought to the front (foregrounding timeout, picker error, confirmation tap error, extension connect timeout) returned with the runner's blank screen still in front. It then fed itself: the next attempt found the runner already frontmost (runnerIsActive), sopreviousAppstayed nil and nothing was restored, even when that attempt succeeded.On the BYOD host (.88.200), 7 of 10 WDA phones were stuck like this. The phones lie on their side, so the blank runner rotated to landscape, and viewers saw a black, sideways frame.
Fix
The dance runs inside
@try/@finally(the same patternstartBroadcastWithTimeoutalready uses), and the foreground is handed back on every exit whenrestoreForegroundAppis set: to the previously active app if one is known, otherwise to SpringBoard viafb_goToHomescreenWithError(a HOME button press does not reach SpringBoard on iOS 26). The dance body moves unchanged intorunBroadcastDanceWithRunner:….Verification
Scripts/ci/build-real.sh(schemeWebDriverAgentRunnerTunnel): build succeeded, no new warnings.…14DA001C, lying on its side): after a failed start the foreground is nowcom.apple.springboard, PORTRAIT (previously the runner, LANDSCAPE).The failure itself (408 on sideways phones) is fixed separately in #41.
Linear: DRO-3369
🤖 Generated with Claude Code