Toolbar: restore setSafeArea on StatusBar button branch (#4814 regression)#4815
Merged
Conversation
…sion) The fix in #4814 wrapped the StatusBar component creation in an if/else but only set setSafeArea(true) on the Container fallback. With the default statusBarScrollsUpBool=true the new Button branch ran without safe-area treatment, so the iOS top inset was no longer reserved and every form shifted vertically. iOS screenshot tests caught this: 36 of 37 baselines diverged on the merge commit. Move setSafeArea(true) below the if/else so it applies to both the Button and Container cases, matching the pre-#4814 behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous fix attempt ran into a compile error because Component.setSafeArea does not exist - setSafeArea is only defined on Container. Replacing the StatusBar Container with a Button (as #4814 did) therefore drops safe-area support entirely, which is what made 36 of 37 iOS screenshot baselines diverge. Keep the StatusBar as a Container (so setSafeArea(true) and the StatusBar UIID styling continue to apply unchanged), and attach a pointer-released listener to it for the scroll-to-top behavior #4814 introduced. The synthetic iOS tap forwarded by cn1StatusBarTapProxy still fires Component.pointerReleased, which dispatches to that listener. 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
|
Compared 37 screenshots: 37 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
iOS screenshot updatesCompared 37 screenshots: 36 matched, 1 updated.
Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
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.
Summary
setSafeArea(true)on theContainerfallback. With the defaultstatusBarScrollsUpBool=true, the newButtonbranch ran without safe-area treatment, so the iOS top inset was no longer reserved and every form shifted vertically.setSafeArea(true)below the if/else so it applies to both branches, matching the pre-Fix tap-status-bar-to-scroll when global Toolbar is in use (#3589) #4814 behavior. The scroll-to-top fix from Fix tap-status-bar-to-scroll when global Toolbar is in use (#3589) #4814 is preserved.Bisect evidence (scripts-ios.yml on master)
All 36 failing tests still produce 1179x2556 px images (same dims as goldens), so the differences are pixel content from the missing top inset.
Test plan
Test iOS UI build scriptsworkflow passes on this branch with screenshots matching stored references.🤖 Generated with Claude Code