Repository navigation
fix: present the broadcast picker in portrait on phones lying on their side (DRO-3369) - #41
Merged
Merged
Conversation
…r side The picker host window used a plain view controller, so the runner followed the device: on a phone lying on its side it came up in landscape, and SpringBoard presented the Control Center broadcast sheet in landscape to match. The confirmation tap then landed outside the sheet's "Start Broadcast" button, dismissing the sheet instead, so replayd never started a session and every start timed out with 408 (DRO-3369). Pin the picker host to portrait (portrait-only root view controller, scene geometry request on iOS 16+) and wait for the scene to turn before firing the picker, so the sheet appears as on an upright phone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
niko-droidrun
approved these changes
Oct 15, 2026
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.
Follow-up to #40, which made a failed broadcast start hand the foreground back but did not fix the failure itself.
Problem
On phones lying on their side (the BYOD host .88.200), every broadcast start failed with 408 ("the broadcast was confirmed but the extension did not connect in time").
FBBroadcastPickerHosthosted the picker in a window whose root view controller allowed every orientation, so the runner followed the device into landscape. SpringBoard then presented the Control Center "Screen Broadcast" sheet in landscape to match. The confirmation tap landed outside the "Start Broadcast" button, which dismisses the sheet. Evidence from…14DA001C(iOS 26.6.1):broadcast/start: confirmation tapped after 1658ms, then nothing from replayd (no session start, no extension launch) untilextension connect timeout after 31752msOn an upright phone the sheet and the tap mapping agree, which is why only sideways phones were affected. (Tapping through SpringBoard instead of the runner did not help: both mappings are wrong for a landscape sheet.)
Fix
The picker host gets a portrait-only root view controller, requests a portrait scene geometry (iOS 16+;
attemptRotationToDeviceOrientationbefore that), and waits up to 2 s for the scene to turn before firing the picker. The sheet then appears exactly as on an upright phone.Verification
Scripts/ci/build-real.sh(schemeWebDriverAgentRunnerTunnel): build succeeded, no new warnings.…14DA001Clying on its side (runs master + this commit): syslogBroadcast picker host rotated to portrait→confirmation tapped after 1901ms→extension connected after 5212ms, twice in a row (setup check + portal start). Broadcastconnected, ReplayKit orientation1, ~16 fps of frames arriving, SpringBoard PORTRAIT in front.Not yet tested: a start while a landscape app is in front (e.g. Safari rotated). Portrait is forced only for the dance, and #40 restores that app afterwards.
Linear: DRO-3369
🤖 Generated with Claude Code