iOS: orientation-validate canvas size on iPad foreground (#4767)#4853
Merged
shai-almog merged 1 commit intomasterfrom May 3, 2026
Merged
iOS: orientation-validate canvas size on iPad foreground (#4767)#4853shai-almog merged 1 commit intomasterfrom
shai-almog merged 1 commit intomasterfrom
Conversation
The previous attempt (a09b916) silenced viewWillTransitionToSize: during background but then called updateCanvas: synchronously inside cn1ApplicationWillEnterForeground. On iPad with UIScene, view.bounds can still be in the snapshot orientation at that moment, so updateCanvas republished the swapped dimensions through screenSizeChanged -- the same behavior the issue reports as a transient wrong size between stop and start. This change combines two safeguards: it restores the next-runloop deferral around the foreground updateCanvas call so UIKit has a tick to settle the bounds, and it cross-checks the sampled size against the windowScene's interfaceOrientation, swapping the dimensions when they contradict it. The orientation is authoritative for what the user actually sees, so this catches the failure even when the deferred call still fires before UIKit has fully restored bounds. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 79 screenshots: 79 matched. Benchmark Results
Build and Run Timing
|
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
1 participant
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.
Summary
updateCanvas:incn1ApplicationWillEnterForegroundso UIKit has a tick to settle view bounds after the snapshot rotation.view.boundsagainst the windowScene'sinterfaceOrientationinsideupdateCanvas:and swaps the dimensions when they contradict it -- catches the failure even when the deferred call still fires before UIKit has restored bounds.Why
Previous attempt (#4808 / a09b916) correctly filters
viewWillTransitionToSize:during the background snapshot pass, but it then callsupdateCanvas:synchronously insidecn1ApplicationWillEnterForeground. On iPad with UIScene,view.boundsis still in the snapshot orientation at that point, so the synchronous call republishes the swapped dimensions throughscreenSizeChanged-- the exact transient wrong size the user reports between stop and start in #4767.The interface orientation reported by the windowScene is authoritative for what the user actually sees, so it can be used as a tiebreaker when the bounds and the orientation disagree.
Test plan
screenSizeChangedbetween stop and start.screenSizeChangedbetween stop and start.viewWillTransitionToSize:) still propagates correctly.ios.uiscene=false) builds still behave correctly.Fixes #4767
🤖 Generated with Claude Code