[Due for payment 2026-08-21] [$250] Android - Company cards - Learn more banner is broken after rotating device to portrait

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.45-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96627
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace settings > Company cards.
3. Rotate device to landscape.
4. Rotate device to portrait.

Expected Result:

Learn more banner will not change its layout after rotating device to portrait.

Actual Result:

Learn more banner is broken after rotating device to portrait.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7219119_1785180994220.Screen_Recording_20260728_033429_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219119

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081842726491970492
• Upwork Job ID: 2081842726491970492
• Last Price Increase: 2026-07-29

Issue Owner

Current Issue Owner: @mallenexpensify

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/5b4049a828523275a678e214c48aa715217ba4b57fc0ccbfdc4b11192fb19356

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Workspace settings > Company cards, the empty-state "Learn more" banner (illustration + "Add cards" CTA) renders broken after rotating an Android device landscape → portrait. Reproducible in staging and production, so this is pre-existing and independent of PR #96627 (the Button→ButtonComposed migration it was caught under).

What is the root cause of that problem?

The banner illustration is given a hard-coded 680px width in the "narrow" layout branch:

• src/styles/index.ts:6822 — getEmptyStateCompanyCardsIllustration returns {width: 680, height: 220} when narrow.
• src/styles/index.ts:6820 — the container returns {height: 220} when narrow vs. the fluid {aspectRatio: 680/220} when wide.

On native, useResponsiveLayout/index.native.ts:37 hard-codes isSmallScreenWidth = true, so shouldUseNarrowLayout is always true regardless of orientation. The banner therefore always uses the fixed 680px illustration box, which is wider than a portrait phone (~360–412dp) but fits in landscape (~800dp+). The box is centered inside a container with overflow: 'hidden', so after rotating back to portrait the over-wide 680px illustration is left clipped/off-center instead of reflowing to the current width. On web this doesn't reproduce because useResponsiveLayout derives the flag from live windowWidth.

Render chain

WorkspaceCompanyCardsPage → WorkspaceCompanyCardsTable (empty branch) → WorkspaceCompanyCardPageEmptyState.tsx:140-141 (applies the two style factories) → FeatureList → Section (overflow: 'hidden' illustration container). The illustration is a static ImageSVG with contentFit="contain", not a video/Lottie.

What changes do you think we should make in order to solve the problem?

Make the narrow-branch illustration width-responsive instead of a fixed 680px so it always fits the current window width and reflows on rotation, mirroring the wide branch:

• src/styles/index.ts:6822: narrow branch → {width: '100%', maxWidth: 680, height: 220} (or {width: '100%', height: '100%'} paired with a fluid container).
• src/styles/index.ts:6820: narrow container → {width: '100%', aspectRatio: 680/220} so it scales with width.

Minimal alternative: add maxWidth: '100%' to the illustration style so the 680px can never exceed the clipping parent in portrait.

Also check the Expensify Card empty state — src/styles/index.ts:5621 (expensifyCardIllustrationContainer) uses the same fixed-680 pattern and likely shares this bug.

Confidence

Medium — the fixed-680 + always-narrow-native + overflow:hidden mechanism is confirmed in code and fully explains the symptom, but the exact broken-portrait rendering after rotation was not reproduced on-device. An Android emulator repro on the Company cards empty state (rotate landscape→portrait) would confirm before landing.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97156) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thelullabyy (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022081842726491970492

[thelullabyy]

@MelvinBot Could you please provide branch for me to test your solution?

[MelvinBot]

🤖 Here's a branch you can test the solution on:

• Branch: claude-companyCardsBannerRotation
• Draft PR: Fix Company cards empty-state banner broken after rotating to portrait #97257

What it changes: adds maxWidth: '100%' to the narrow-layout Company cards empty-state illustration (src/styles/index.ts:6828). The banner illustration had a hard-coded width: 680, which is wider than a portrait phone; on native shouldUseNarrowLayout is always true, so the box kept the fixed 680px width and stayed clipped after rotating landscape → portrait. Capping it at the container width lets the contentFit="contain" illustration reflow on rotation while still using up to 680px where there's room.

How to test (Android):

1. Go to Workspace settings > Company cards (empty state — the "Learn more" banner).
2. Rotate the device to landscape, then back to portrait.
3. Verify the banner illustration reflows to fit the width and is no longer broken/clipped.

I've assigned you and left it as a draft — mark it "Ready for review" once you're happy with it.

Local checks run

• npm run typecheck-tsgo — passed
• npm run lint-changed — passed

Full Jest / Storybook / on-device platform checks run in CI and during your review. This is a native rotation bug, so I couldn't reproduce it on an emulator myself — the on-device verification is the key thing to confirm.

[thelullabyy]

🆘 C+ Help Wanted

[aswin-s]

Please re-state the problem that we are trying to solve in this issue.

On Android, the "Learn more" Expensify Card promotion banner in workspace settings → Company cards shows a broken layout after rotating the device from landscape back to portrait. Expected: the banner returns to its portrait layout after rotation. Actual: the Learn More button loses its full-width stretch and is mis-sized.

What is the root cause of that problem?

PR #96627 migrated the Learn More button in src/pages/workspace/companyCards/WorkspaceCompanyCardExpensifyCardPromotionBanner.tsx from the legacy Button (src/components/Button/index.tsx) to ButtonComposed/Button (src/components/ButtonComposed/Button.tsx). Two things combine to produce the bug:

1. Boolean false injected into wrapperStyle.

The call site passes:

style={shouldUseNarrowLayout && !isInLandscapeMode && styles.flex1}

In landscape mode this expression evaluates to the boolean false. Both the legacy Button and ButtonComposed/Button place the style prop into the wrapperStyle array of PressableWithFeedback:

// ButtonComposed/Button.tsx
wrapperStyle={[
    isDisabled && !stayNormalOnDisable ? {...styles.cursorDisabled, ...styles.noSelect} : {},
    styles.buttonContainer,
    removeBorderRadius ? borderRadiusStyles[removeBorderRadius] : undefined,
    style,   // ← `false` lands here in landscape
]}

The parameter default style = [] does not substitute false — JavaScript destructuring defaults activate only on undefined. So false is passed as a live element inside the wrapperStyle array, which causes React Native to see a malformed style array entry during the landscape render.

2. The wrapperStyle corruption invalidates the Android view tree at rotation.

React Native's layout engine on Android re-measures views on orientation change. When the component re-renders back to portrait, the previously corrupted wrapperStyle (containing false) has left the native view tree in an inconsistent state. The outer wrapper recovers the flex1 shape, but the pressable's own size — governed by buttonContainerStyles in ButtonComposed/Button.tsx — is not re-negotiated correctly after the bad landscape pass.

This is why the breakage only manifests after the landscape→portrait transition, not on a cold portrait launch: in a cold portrait launch the expression evaluates to styles.flex1 (truthy), wrapperStyle is clean, and no stale native layout state exists.

3. The innerStyles merge conflict.

The call site also passes innerStyles={!canUseLearnMore ? styles.buttonOpacityDisabled : undefined}. This is a single conditional expression, not an array. Moving flex1 to innerStyles as a fix requires merging it with this expression; failing to merge would silently discard one branch.

What changes do you think we should make in order to solve the problem?

In src/pages/workspace/companyCards/WorkspaceCompanyCardExpensifyCardPromotionBanner.tsx, eliminate the && expression that produces boolean false by switching to an explicit ternary, and move flex1 into innerStyles so it applies via the pressable's own buttonStyles path rather than the outer wrapperStyle. Merge it with the existing innerStyles disabled-opacity branch into a single array:

Before (lines 62–65):

<Button
    variant={CONST.BUTTON_VARIANT.SUCCESS}
    onPress={canUseLearnMore ? handleLearnMore : onReadOnlyAction}
    style={shouldUseNarrowLayout && !isInLandscapeMode && styles.flex1}
    innerStyles={!canUseLearnMore ? styles.buttonOpacityDisabled : undefined}

After:

<Button
    variant={CONST.BUTTON_VARIANT.SUCCESS}
    onPress={canUseLearnMore ? handleLearnMore : onReadOnlyAction}
    innerStyles={[
        shouldUseNarrowLayout && !isInLandscapeMode ? styles.flex1 : undefined,
        !canUseLearnMore ? styles.buttonOpacityDisabled : undefined,
    ]}

This:

• Removes the && short-circuit that produces boolean false (replaced by an explicit ternary whose falsy branch is undefined)
• Moves flex1 to innerStyles, which feeds into buttonStyles at ButtonComposed/Button.tsx:111 — the style prop of the pressable itself — so the pressable stretches, not just the outer wrapper
• Merges cleanly with the existing disabled-opacity innerStyles usage (which would otherwise conflict or silently lose one branch)
• Leaves the style prop absent, so the parameter default style = [] activates correctly

State	Before	After
Portrait (narrow, not landscape)	style=flex1 on wrapperStyle; pressable sizing depends on re-render history	innerStyles=[flex1, ...] applied directly to pressable → stretches correctly
Landscape	style=false → corrupt wrapperStyle array entry	innerStyles=[undefined, ...] → no stretch, correct wide layout
Back to portrait	Stale native layout from corrupt landscape pass; button collapses	Clean wrapperStyle history; pressable regains flex1, stretches correctly

What alternative solutions did you explore? (Optional)

• Array-normalize style only (style={[shouldUseNarrowLayout && !isInLandscapeMode ? styles.flex1 : {}]}): fixes the false injection into wrapperStyle but still places flex1 on the outer wrapper rather than the pressable itself. The layout pass inconsistency between the wrapper and the pressable remains. Rejected as incomplete.

• Fix in ButtonComposed/Button.tsx (coerce false → [] for the style parameter): would globally prevent false from reaching wrapperStyle, but the mismatch between where flex1 lands (wrapper vs. pressable) would persist for any call site relying on style for flex sizing. Rejected as the wrong layer — the defect is that this call site should be using innerStyles for its intent.

[mukhrr]

Proposal

What is the root cause of that problem?

I extracted the video attached to the issue and stepped through it frame by frame, and the broken element is not the button — it is the banner's title/subtitle column. After the landscape → portrait round trip, the title and the subtitle each render one character per line, which is what makes the banner grow to several screens tall. The text column's left edge is unchanged, and the "Learn more" pill sits to the right of that one-character column (vertically centred in the now enormous flex line) instead of below it.

That geometry tells us the flex: 1 title/subtitle container has resolved to zero width, because the right component is sharing its flex line and taking all of the line's remaining space:

App/src/pages/settings/Subscription/CardSection/BillingBanner/BillingBanner.tsx

Lines 124 to 131 in a53b963

	<View style={[styles.pv4, styles.ph5, styles.flexRow, styles.flexWrap, styles.gap3, styles.w100, styles.alignItemsCenter, styles.trialBannerBackgroundColor, style]}>
	<Icon
	src={icon}
	width={variables.menuIconSize}
	height={variables.menuIconSize}
	/>
	<View style={[styles.flex1, styles.justifyContentCenter]}>

The reason it normally does not share that line is subtle: BillingBanner's row is flexWrap, and the narrow-portrait layout of this banner forces the line break by giving the right component a percentage flex basis that is as wide as the whole row:

App/src/pages/workspace/companyCards/WorkspaceCompanyCardExpensifyCardPromotionBanner.tsx

Lines 56 to 72 in a53b963

	const rightComponent = useMemo(() => {
	const smallScreenStyle = shouldUseNarrowLayout && !isInLandscapeMode ? [styles.flex0, styles.flexBasis100, styles.maxWidth100Percentage, styles.justifyContentCenter] : [];
	return (
	<View style={[styles.flexRow, styles.gap2, smallScreenStyle]}>
	<Button
	variant={CONST.BUTTON_VARIANT.SUCCESS}
	onPress={canUseLearnMore ? handleLearnMore : onReadOnlyAction}
	style={shouldUseNarrowLayout && !isInLandscapeMode && styles.flex1}
	innerStyles={!canUseLearnMore ? styles.buttonOpacityDisabled : undefined}
	hoverStyles={!canUseLearnMore ? styles.buttonOpacityDisabled : undefined}
	accessibilityLabel={`${translate('workspace.moreFeatures.companyCards.expensifyCardBannerLearnMoreButton')}, ${translate('workspace.moreFeatures.companyCards.expensifyCardBannerTitle')}`}
	>
	<Button.Text>{translate('workspace.moreFeatures.companyCards.expensifyCardBannerLearnMoreButton')}</Button.Text>
	</Button>
	</View>
	);
	}, [styles, shouldUseNarrowLayout, isInLandscapeMode, translate, canUseLearnMore, handleLearnMore, onReadOnlyAction]);

flexBasis: '100%' with flex: 0 (so flexShrink: 0) is a flex-line input: it is what Yoga consults when it decides where to break lines and how to distribute space along a line. In the healthy first layout it exceeds the space left after the icon, so the item overflows onto its own line and the text column keeps its full width. After the window size changes and the existing shadow tree is re-laid-out, the item ends up placed on the first line instead, sized to the leftover space rather than to the container's inner width — so the flex: 1 text column is left with nothing.

isInLandscapeMode itself is a plain derivation of the frame dimensions, so a stale value cannot explain the symptom on its own: with the landscape branch applied at portrait width the button would be content sized (~124dp) and the text column would still be ~144dp wide, not one character. The collapse only happens with the full-row basis applied, which is why I believe the line-break behaviour is the actual defect:

App/src/hooks/useResponsiveLayout/index.native.ts

Lines 34 to 36 in a53b963

	const isInLandscapeMode = isInLandscapeModeUtil(windowWidth, windowHeight);
	const isExtraSmallScreenHeight = windowHeight <= variables.extraSmallMobileResponsiveHeightBreakpoint;

I want to be explicit that I verified the geometry (collapsed text column, button on the same line) from the recording, and inferred the Yoga-internal reason the break stops happening from that geometry rather than instrumenting Yoga directly.

What changes do you think we should make in order to solve the problem?

I think we should stop expressing "this row occupies its own line" as a percentage flex basis, and express it as a definite width that cannot be re-resolved against the leftover space of a line, plus an explicit flexShrink: 0:

-const smallScreenStyle = shouldUseNarrowLayout && !isInLandscapeMode ? [styles.flex0, styles.flexBasis100, styles.maxWidth100Percentage, styles.justifyContentCenter] : [];
+const smallScreenStyle = shouldUseNarrowLayout && !isInLandscapeMode ? [styles.w100, styles.flexShrink0, styles.justifyContentCenter] : [];

width: '100%' is resolved against the parent's inner width as a dimension rather than as a flex-line input, so the row is pinned to the banner's full inner width in every layout pass and cannot settle on "whatever was left on the first line". maxWidth: '100%' becomes redundant once the width is exactly 100%, and flex: 0 is replaced by the flexShrink: 0 it was really there for.

Everything else stays as it is: the button keeps styles.flex1 so it still fills the full-width row in portrait, the landscape branch is untouched (empty style array, content-sized button), and the navigation, permission, disabled-appearance and accessibility-label behaviour are unchanged.

I verified this with a focused test that renders the banner with useResponsiveLayout mocked for both orientations and asserts the right component's resolved wrapper style — a definite full width and no shrink in portrait, content sized in landscape. It fails on the current code (Expected: "100%", Received: undefined) and passes with the change.

QA should check portrait, landscape, and several repeated landscape → portrait rotations on Android, plus the existing narrow mWeb layout.

What alternative solutions did you explore? (Optional)

I considered fixing this inside BillingBanner by making it an explicit column in the shouldUseNarrowLayout && !isInLandscapeMode case, which would remove the wrap dependency entirely rather than making it more robust. I decided against it because the other BillingBanner callers — CardSection and HRProviderCard — pass small content-sized right components with no full-row style and deliberately keep them on the same line in narrow portrait, so turning the row into a column would change their layout too. Keeping the change in this one caller matches where the full-row layout is actually requested.

I also want to flag that the contentContainerStyle={styles.flex1} fix suggested earlier in this thread cannot address this: contentContainerStyle lands on the View inside the pressable, which has no influence over whether the right component shares a flex line with BillingBanner's title/subtitle column — and it is that column, not the button's inner content, that collapses in the recording.