android: stabilize custom top bar button layout#8326
Merged
Conversation
8e7e2fd to
15e8032
Compare
baeb5a9 to
cdab8da
Compare
cdab8da to
26e2471
Compare
israelko
added a commit
that referenced
this pull request
Jun 11, 2026
…e bounded measure Custom React-component top bar buttons without explicit width/height collapsed to ~1px (invisible) under the New Architecture (Fabric). The two-pass measurement from #8320/#8326 re-measured the hosted ReactSurfaceView with an EXACTLY box derived from the first (often still-empty) discovery pass; that forced box is pushed to Fabric via updateLayoutSpecs, so Fabric keeps laying the content out into the collapsed box and the button never recovers. The same forcing also stretched flex-content buttons to the full bar height. Replace the two-pass with a single bounded (AT_MOST) measure and let ReactSurfaceView size itself to its content (its documented AT_MOST max-of-children behavior). When Fabric mounts/sizes the content it re-requests layout and this measure runs again against the real content size. Explicit width/height still measure EXACTLY; vertical centering is preserved by the existing CENTER_VERTICAL gravity. Verified on-device (Pixel 7, newArch+Hermes) on RN 0.78.3 and 0.85.2: content-hugging and flex component buttons render correctly; flex buttons are pixel-identical to before. Unit tests updated for the single-pass contract. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
yedidyak
pushed a commit
that referenced
this pull request
Jun 14, 2026
…lapse fix) (#8328) * android: re-measure custom top bar button when async React content reports its size On the New Architecture (Fabric), a custom React-component top bar button without explicit width/height could collapse to ~1px. The hosted React surface lays out asynchronously, off the native measure pass, so the first onMeasure often observes a 0-sized child and freezes the button at the ~1px floor with no subsequent re-measure. Attach an OnLayoutChangeListener to the hosted child that re-requests layout when the content's size changes (so onMeasure re-runs and sizes the button to the content). The size-changed guard makes it converge once the button matches the content. The explicit-dimensions check is done inside the listener because onViewAdded fires from the superclass constructor (before `component` is assigned) for the React surface view we need to observe. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore: re-trigger CI Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * remove `require-label.yml` workflow (as Yogi suggested 😀) * test: make collapsed-width assertion density-independent The new test hardcoded the collapsed button width as 1px, which only holds at mdpi (density 1.0). CI runs at a higher density, where resolveFinalWidth(0) = ceil(dpToPx(1dp)) > 1. Derive the expected value from the same dpToPx formula the production code uses instead of hardcoding it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test: invalidate child measure cache before re-measure assertion The re-measure assertion failed (expected 25 but was 1) because View.measure() caches results: re-measuring the button with the same outer spec reused the child's stale cached 0-width measurement, so resolveFinalWidth still saw 0. In production RN re-measures the surface when it lays out new content; model that with child.forceLayout() (after child.layout(), which clears FORCE_LAYOUT) so the parent's super.onMeasure observes the real content width. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * android: size custom top-bar component buttons to content via a single bounded measure Custom React-component top bar buttons without explicit width/height collapsed to ~1px (invisible) under the New Architecture (Fabric). The two-pass measurement from #8320/#8326 re-measured the hosted ReactSurfaceView with an EXACTLY box derived from the first (often still-empty) discovery pass; that forced box is pushed to Fabric via updateLayoutSpecs, so Fabric keeps laying the content out into the collapsed box and the button never recovers. The same forcing also stretched flex-content buttons to the full bar height. Replace the two-pass with a single bounded (AT_MOST) measure and let ReactSurfaceView size itself to its content (its documented AT_MOST max-of-children behavior). When Fabric mounts/sizes the content it re-requests layout and this measure runs again against the real content size. Explicit width/height still measure EXACTLY; vertical centering is preserved by the existing CENTER_VERTICAL gravity. Verified on-device (Pixel 7, newArch+Hermes) on RN 0.78.3 and 0.85.2: content-hugging and flex component buttons render correctly; flex buttons are pixel-identical to before. Unit tests updated for the single-pass contract. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * android: measure custom top-bar button height EXACTLY to keep content vertically centered The previous commit fixed the collapse by measuring the React surface with a single bounded (AT_MOST) pass, but using AT_MOST for the *height* let content-hugging surfaces shrink, which shifted self-centering content (e.g. a flex container with justifyContent:'center') downward — the playground buttons_navbar snapshot caught this as an off-center round button on Fabric. Measure the height EXACTLY to the available bar height instead. A filled height box lets the React content center itself in the bar (matching the legacy two-pass layout), while the width stays AT_MOST so the surface still sizes to its content and the collapse fix is preserved (forcing the width is what caused the collapse; forcing the height does not). Verified on a Pixel 3a / API emulator (the CI device profile) in release: the buttons_navbar snapshot test passes (centering matches), and the full Buttons (14/14) and Stack (20/20) Detox suites pass. Unit tests updated for the filled-height contract. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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
Validation
git diff --check./gradlew :react-native-navigation:testDebugUnitTest --tests com.reactnativenavigation.views.TitleBarReactButtonViewTest --tests com.reactnativenavigation.views.TitleAndButtonsContainerTest— SUCCESS (37 successes, 0 failures, 0 skipped)Not Run
Risks
Review Context
AT_MOSTwidth to prevent title truncation.Suggested Reviewers
TitleBarReactButtonViewand the new regression tests in android: fix custom top bar button measurement #8320.