[Due for payment 2026-09-22] Expense - Change workspace list is not scrollable in landscape when search field is focused

[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.77-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: #99236
Email or phone of affected tester (no customers): sdjnoisosdiso@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: Money Requests

Action Performed:

Precondition:

• Have at least 12 workspaces.

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Open the report.
5. Tap More > Change workspace.
6. Switch to landscape mode.
7. Focus on the search field.
8. Scroll the list.

Expected Result:

Change workspace list will be scrollable in landscape mode when search field is focused.

Actual Result:

Change workspace list is not scrollable in landscape mode when search field is focused.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7257545_1789166632958.Screen_Recording_20260912_062110_Expensify.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @truph01

[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/3e66a2d90d9044dfe920214d115a7f8a1b140f20f7c47547e618995006940e97

[melvin-bot]

@mountiny recently merged #99236, but they are OOO right now, so I'll auto-assign someone else.

[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]

Triggered auto assignment to @amyevans (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

@mountiny @truph01 you have been assigned to this deploy blocker because you reviewed the offending PR: #99236

[melvin-bot]

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

[MelvinBot]

Proposal

TL;DR: Expensify/App#99236 caused this. Recommend reverting it. It is the only PR in this release that touches this screen, and it added a fixed footer that leaves no room for the list once the keyboard opens in landscape.

What is the root cause of that problem?

Expensify/App#99236 gated the workspace picker behind a Save button. That adds a FixedFooter to a screen that already has a fixed header and a fixed search input. FixedFooter is flexShrink: 0, so the list is the only child that can shrink.

When you focus the search field, KeyboardAvoidingView subtracts the keyboard height from the viewport. In landscape there is not enough height left, so the list collapses to roughly zero and stops scrolling. Portrait still has enough room, which is why only landscape breaks.

Rough numbers on the reported device (Galaxy S25 FE, ~393dp landscape height, ~200dp keyboard): header 72dp + search 58dp + footer 72dp ≈ 202dp of unshrinkable chrome against ~190dp of available space. Before this PR the chrome was ~130dp, leaving ~60dp — one row, still scrollable.

Evidence

• git diff production...staging shows exactly two files in this flow changed in the whole release: src/pages/DynamicReportChangeWorkspacePage.tsx (+17/-4) and src/hooks/useWorkspaceList.ts (+9/-2). Both are from Expensify/App#99236.
• No shared layout component (SelectionList/, ScreenWrapper/, FixedFooter, KeyboardAvoidingView) changed in this release, which rules out a generic list or keyboard regression from another PR.
• The new footer is added at DynamicReportChangeWorkspacePage.tsx:248-253 and passed in at :283.
• That flag sets hasFooter at BaseSelectionList.tsx:130 and renders the footer as a sibling of the list at :552.
• The search input sits outside the list (TextInput.tsx:153-185), so it is fixed height too.
• Supporting hint that landscape was already tight: the code deliberately skips autofocus in landscape at TextInput.tsx:121-137. The bug only shows when you focus the field by hand, which is exactly what QA did.

Candidate ruled out: Expensify/App#100724 (react-native-keyboard-controller 1.22.4). Its diff is only lockfiles plus a 100%-similarity rename of the existing Android landscape-insets patch, byte-identical content. A library-wide keyboard regression would break keyboard-open lists everywhere, not just the one screen that simultaneously gained a footer. Keep it as a low-confidence fallback suspect only if the revert does not fix this.

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

Revert Expensify/App#99236, then re-land it with landscape handling.

The revert is clean. The only shared-code change is the new policyIDsToSortToTop param in useWorkspaceList.ts, consumed solely by DynamicReportChangeWorkspacePage.tsx. Nothing else references it, so no dependent PRs break.

What alternative solutions did you explore?

A targeted roll-forward, but it is worse under deploy-blocker time pressure. The honest fix is layout surgery in the shared BaseSelectionList: either collapse the FixedFooter while the keyboard is open, or move the search input inside the list via textInputOptions.shouldBeInsideList so it scrolls away. Either change affects roughly 30 pages that use confirmButtonOptions. That belongs in the re-land, not in a hotfix.

Also worth checking

• SetDefaultWorkspacePage.tsx:110-127 got the identical footer + search combination in the same PR, so the Category → workspace picker flow very likely has the same landscape defect.
• Sibling accessibility PRs Expensify/App#99238 and Expensify/App#99239 apply the same "gate selection behind a Save footer" pattern to other screens. They deserve a landscape spot-check.

Confidence

High on the causing PR. Medium-high on the exact layout mechanism — I traced it through the code but did not reproduce it on an Android device in landscape, so the dp arithmetic above is an estimate rather than a measurement. Reverting and re-testing step 8 in landscape will confirm it.

---

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

---

view run · no recording available