[Due for payment 2026-07-13] Android - Workspace - Contact list modal does not move up when keyboard is opened

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94392
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.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:

• Log in with Expensifail account.
• Create a Submit workspace on OD.

1. Launch Expensify app.
2. Go to workspace chat.
3. Create an expense.
4. Tap Submit.
5. Tap on the search field.

Expected Result:

Contact list modal will move up when keyboard is opened.

Actual Result:

Contact list modal does not move up when keyboard is opened.
The modal is blocked by the keyboard.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7196904_1782937302738.Screen_Recording_20260702_041923_Expensify.mp4

View all open jobs on GitHub

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

[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/59cce6758751a7fba17ac3311d756b17633c3816b5db624c15c40c6b20529508

[melvin-bot]

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

[melvin-bot]

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

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The submit-to popover added in #94392 renders a SelectionList with a search text input, but the popover's modal is not told to avoid the keyboard. On Android a bottom-docked modal only rises above the keyboard when it is wrapped in a KeyboardAvoidingView, and that wrapper is gated entirely on the avoidKeyboard prop.

useReportSubmitToPopover renders PopoverWithMeasuredContent without avoidKeyboard, so it defaults to false and that value propagates all the way down to the modal, meaning the contact list never moves up and the keyboard covers it.

Evidence chain

• useReportSubmitToPopover.tsx:202-218 — PopoverWithMeasuredContent is rendered with no avoidKeyboard prop.
• PopoverWithMeasuredContentBase.tsx:40 — default is avoidKeyboard = false, and it is forwarded down (line 204).
• ReanimatedModal/index.tsx:249-256 — content is only wrapped in KeyboardAvoidingView when avoidKeyboard is true; otherwise there is no keyboard avoidance.
• Comparable popover selectors that behave correctly on Android both set the prop: EmojiPicker.tsx:271 and FilterPopupButton.tsx:110.

This is Android-specific because web hardcodes avoidKeyboard={false} at the Modal layer, while Android forwards the caller's value through to BaseModal.

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

Add the avoidKeyboard prop to the PopoverWithMeasuredContent rendered in useReportSubmitToPopover.tsx, matching how EmojiPicker and FilterPopupButton do it. This wraps the bottom-docked modal in a KeyboardAvoidingView so the contact list rises above the keyboard on Android.

Please verify the bottom-docked-in-landscape path (isBottomDockedInLandscape) still lays out correctly with avoidKeyboard alongside the existing height styles, though the two reference popovers set it unconditionally without issue.

What alternative solutions did you explore? (Optional)

N/A — the missing prop is the direct cause.

Possibly related: #91693 ("Filter report field search box is hidden by keypad in landscape mode") is a separate feature but the same class of keyboard-avoidance bug.

Confidence: High — verified against the code; the two working reference selectors confirm the mechanism.

---

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

[hungvu193]

We can demote. This modal only show up with submit ws