Android - Copilot - Copilot button is out of view after rotating device to landscape

[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.78-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100817
Email or phone of affected tester (no customers): sdiuhbdsiuhusih@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Other

Action Performed:

Precondition:

• Have copilot access to any account.

1. Launch Expensify app.
2. Go to Account.
3. Rotate device to landscape.
4. Rotate device to portrait.
5. Rotate device to landscape.
6. Repeat Step 3 to 5 a few times.

Expected Result:

Copilot button will not be out of view after rotating device to landscape.

Actual Result:

Copilot button is out of view after rotating device to landscape.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7259903_1789436105584.Screen_Recording_20260915_093330_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7259903

[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/2c6fc4b12fbc3cede5befd47d175fa209389e1e613870671d81b2b7ff808cfc9

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #100817

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

@stitesExpensify @grgia @huult you have been assigned to this deploy blocker because you reviewed the offending PR: #100817

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #100817 - "[Design Polish] Use a bigger centered avatar and h1 name on the Account page on mobile" by @MelvinBot (High confidence)
Related Issues: #101151 (Copilot tooltip out of view — same PR, same header), #101132 (deploy checklist)

Recommendation: REVERT

#100817 made the Account header layout depend on device orientation, and the tall stacked header it introduced does not fit a landscape phone, so the Copilot ("Switch") button — the last element of the header column — lands below the visible area. This is now the second deploy blocker from this one design-polish PR (#101151 is the first), so reverting it is cheaper and safer than shipping two separate targeted fixes during the deploy window.

Assigned: @huult, @grgia, @stitesExpensify (approving reviewers of #100817) — already assigned by Melvin, no change needed
Labels: No changes. DeployBlockerCash kept (the fix is in Expensify/App); DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• Staging-only (9.4.78-0), not reproducible on production, and the repro is entirely on the Account page header.
• I diffed the whole release (production...staging, 300 files). The only files in it that touch the Account page header, the account/copilot switcher, responsive layout, safe-area/insets, scroll views or orientation handling are src/components/AccountSwitcher.tsx, src/components/AccountSwitcherSkeletonView/index.tsx, src/pages/settings/InitialSettingsPage.tsx and src/styles/index.ts — all four from [Design Polish] Use a bigger centered avatar and h1 name on the Account page on mobile #100817. Nothing in the release touches useResponsiveLayout, useWindowDimensions, isInLandscapeMode, ScreenWrapper, the bottom tab bar or the Button component.
• [Design Polish] Use a bigger centered avatar and h1 name on the Account page on mobile #100817 merged 2026-09-14 13:21 UTC, inside this release, and is the first change ever to make this header's layout orientation-dependent.
• Proof by elimination: in the non-stacked (landscape) branch the style arrays [Design Polish] Use a bigger centered avatar and h1 name on the Account page on mobile #100817 produces are the same arrays as before the PR (AccountSwitcher.tsx#L281-L306). So a landscape-only regression on this page can only come from the header rendering the stacked (portrait) branch while the device is actually in landscape — which is exactly what the new condition allows.

Verification

Affected files (all line refs on e9e328b):

• src/components/AccountSwitcher.tsx#L273-L277 — shouldStackHeader = shouldUseNarrowLayout && !isInLandscapeMode and avatarSize = XXXX_LARGE when stacked (added by [Design Polish] Use a bigger centered avatar and h1 name on the Account page on mobile #100817).
• src/components/AccountSwitcher.tsx#L281-L292 — the stacked container is a centered column (alignItemsCenter, gap4) instead of the old flexRow.
• src/components/AccountSwitcher.tsx#L339-L354 — the Copilot / "Switch" button, now the last child of that column (i.e. the bottom of the header) instead of the trailing item of a single-line row.
• src/pages/settings/InitialSettingsPage.tsx#L107-L124 — the same shouldStackHeader condition mirrored for the skeleton, and #L162-L172 — the header is the first child of the page ScrollView, so anything past the fold is simply scrolled out of view.
• src/hooks/useResponsiveLayout/index.native.ts#L34 and src/libs/isInLandscapeMode/index.native.ts#L9-L11 — isInLandscapeMode = !isTablet && windowWidth > windowHeight.
• src/hooks/useWindowDimensions/index.native.ts#L9-L11 — those dimensions come from useSafeAreaFrame(), i.e. a native onInsetsChange event, not from a synchronous Dimensions.get().
• src/App.tsx#L91-L96 — the SafeAreaProvider is seeded with frame: {width: 0, height: 0}.

Confirmed #100817 modifies AccountSwitcher.tsx and InitialSettingsPage.tsx; it does not modify the responsive-layout hooks — it is the first consumer to make this header's layout depend on them.

Root Cause

#100817 swaps the Account header between two layouts of very different heights based on orientation. Stacked (portrait) height on a phone at font scale 1:

pv4 16+16 + avatar XXXX_LARGE 100 + gap3 12 + h1 line 28 + gap1 4 + email line ~16 + gap4 16 + button componentSizeSmall 28 ≈ 236dp

A Galaxy S25 FE in landscape is ~360–411dp tall; after the top bar (~52dp) and the bottom tab bar (~64dp) the visible scroll area is only ~245–295dp. So when the stacked branch renders in landscape, the button at the bottom of the column sits at or past the fold and is "out of view" until you scroll. In portrait, or in the pre-#100817 single-row header, the button is always on the first line and always visible.

The stacked branch reaches landscape because isInLandscapeMode is not a reliable synchronous signal:

1. It is asynchronous. windowWidth/windowHeight come from useSafeAreaFrame(), which react-native-safe-area-context updates from a native onInsetsChange event after the view has been re-laid-out, and the provider is seeded with a 0 × 0 frame. 0 > 0 is false, and a stale portrait frame is also false, so "orientation unknown/stale" silently means "portrait" and the tall stacked header is what renders. That is exactly the "rotate back and forth a few times and it happens" signature in the repro — it is a race, not a deterministic every-rotation failure.
2. It is false on tablets by definition (!isTablet && …), so any device classified as a tablet gets the stacked, too-tall header in landscape 100% of the time.

Either way the fix is in Expensify/App, so this is a frontend bug and DeployBlockerCash stays.

If the team prefers to roll forward instead of reverting, the targeted fix is to stop using orientation as a proxy for available height in AccountSwitcher.tsx#L274 and InitialSettingsPage.tsx#L108: gate the stacked header on the actual windowHeight (only stack when the viewport is tall enough for the ~236dp header, e.g. reuse isExtraSmallScreenHeight-style height breakpoints from useResponsiveLayout), which is both stale-tolerant and tablet-correct. That fix would need to be paired with the separate tooltip fix for #101151, which is why a single revert is the recommendation.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: UI-5 Gate height-sensitive layouts on viewport height, not isInLandscapeMode
• Condition: When isInLandscapeMode from useResponsiveLayout() is used to choose between layouts/sizes with materially different heights (avatar size, stacked vs row header, reserved rows), flag it and require a windowHeight based condition instead.
• Why: isInLandscapeMode is !isTablet && windowWidth > windowHeight computed from useSafeAreaFrame(), which arrives asynchronously from a native event and is seeded 0 × 0, so "unknown or stale orientation" evaluates to false (= portrait) and the tall portrait layout renders on a short landscape viewport; it is also always false on tablets. That is the mechanism behind this issue.
• Search pattern: rg -n "isInLandscapeMode" src --glob '*.tsx' and, for each hit, check whether it selects style arrays / component or avatar sizes (a ? [styles…] : [styles…] or ? CONST.AVATAR_SIZE.X : CONST.AVATAR_SIZE.Y ternary) rather than gating behavior like focus or popover max-height.
• Offending code (❌): AccountSwitcher.tsx#L273-L277 and the mirrored InitialSettingsPage.tsx#L107-L117
• Fix (✅): derive the condition from windowHeight / the height breakpoints in useResponsiveLayout/index.native.ts#L34-L44 so the layout only stacks when the viewport is actually tall enough

The full rule file, with the ❌/✅ code inline in App's coding-standards format, would go in Expensify/App itself (.claude/skills/app-coding-standards/rules/). If it's worth adding, a maintainer can open it there as a draft PR.

[shawnborton]

This one definitely seems like a bug. Since it's landscape mode, I don't think we have to treat it as a blocker - we can just do a follow up?