[Due for payment 2026-07-07] [Due for payment 2026-07-06] [$250] Android - Expense - Referral banner shows blank space below

[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.21-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94539
Email or phone of affected tester (no customers): sdospmijosnjos11djoi@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:

1. Launch Expensify app.
2. Open FAB > Create expense > Manual.
3. Enter amount > Next.

Expected Result:

Referral banner will not show blank space below.

Actual Result:

Referral banner shows blank space below.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070727545497827508
• Upwork Job ID: 2070727545497827508
• Last Price Increase: 2026-06-27
• Automatic offers:
• thelullabyy | Reviewer | 111844012

Issue Owner

Current Issue Owner: @thelullabyy

[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/0c2315d2cd37816cff6c6e3cf16a50a4bcae8b0d44ef99bd31e16573b704b3b0

[melvin-bot]

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

[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

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

On Android, the participant selector ("To") page in the manual expense flow (FAB > Create expense > Manual > enter amount > Next) shows a blank gap below the referral banner. This is a deploy blocker introduced by #94539 in this release.

What is the root cause of that problem?

Double bottom safe-area padding. #94539 added addBottomSafeAreaPadding to the SelectionListWithSections on this page (ParticipantSearchResults.tsx:517). On this page the screen container already reserves the bottom inset, so the banner's footer now reserves it a second time → the inset-sized blank gap below the banner.

• This page is wrapped by StepScreenWrapper, which uses ScreenWrapper in legacy mode (no enableEdgeToEdgeBottomSafeAreaPadding), so includeSafeAreaPaddingBottom stays true and the container paints the bottom inset itself (ScreenWrapper/index.tsx:129-144). (inset applied once)
• The new prop routes addBottomSafeAreaPadding → SelectionList Footer → FixedFooter wrapping the banner, which adds pb5 + bottom inset via useSafeAreaPaddings(true). That hook returns the raw inset and ignores the "already consumed" flag, so the footer can't tell the container already added it (FixedFooter.tsx:25-33, useSafeAreaPaddings.ts:42-56). (inset applied twice)

The sibling NewChatPage uses the same banner + prop without a gap because its ScreenWrapper is edge-to-edge (includeSafeAreaPaddingBottom=false), so the footer is the only place the inset is applied. The original bug #94260 that #94539 targeted was on the new manual-expense flow (#94134, already reverted by #94312), so the footer-side fix over-corrected the currently-active legacy flow.

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

For the deploy blocker, revert the one-line addition at ParticipantSearchResults.tsx:517 (or revert/CP-revert #94539). The legacy container already insets the banner correctly, and #94260's flow (#94134) is currently reverted, so this restores correct rendering with the lowest risk and no user-visible regression.

When the new manual-expense flow is re-enabled, re-fix #94260 the consistent way (below) rather than via the footer prop.

What alternative solutions did you explore?

Make this screen edge-to-edge so the inset is owned only by the footer (matching NewChatPage) — e.g. pass enableEdgeToEdgeBottomSafeAreaPadding for this screen via StepScreenWrapper. This is the architecturally-correct fix and what #94539 should have done, but StepScreenWrapper is shared by many IOU step screens, so flipping it globally has a larger blast radius than is appropriate for a time-sensitive deploy blocker. Best done as the follow-up paired with re-enabling the new flow.

Evidence chain (confidence: High)

1. IOURequestStepParticipants → StepScreenWrapper → ScreenWrapper legacy mode → container applies bottom inset (isSafeAreaBottomPaddingApplied=true).
2. ParticipantSearchResults.tsx:517 passes addBottomSafeAreaPadding → BaseSelectionListWithSections → SelectionList/components/Footer.tsx → FixedFooter wrapping ReferralProgramCTA.
3. FixedFooter → useBottomSafeSafeAreaPaddingStyle → useSafeAreaPaddings(true) returns the raw inset (edge-to-edge return path ignores the consumed flag) → footer adds pb5 + inset again.
4. Net on Android: container inset + footer (pb5 + inset) = visible gap below the banner. Most visible on devices with a non-zero bottom inset (gesture/nav bar); zero-inset devices show nothing.

---

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

[thelullabyy]

@MelvinBot Please implement your alternative solution

[MelvinBot]

🤖 Draft PR created (implements the alternative / edge-to-edge solution from my proposal): #94754

What it does: adds an optional enableEdgeToEdgeBottomSafeAreaPadding prop to StepScreenWrapper and sets it only on IOURequestStepParticipants, so the screen container stops reserving the bottom safe-area inset and the SelectionList becomes the single owner of it (via the FixedFooter wrapping the referral banner, or the list content-container padding when there's no footer) — exactly matching NewChatPage. This removes the double padding that caused the blank gap, without reintroducing the original "banner behind the nav bar" bug, and is scoped to this one screen so other StepScreenWrapper usages are unaffected.

Checks run locally: prettier ✓, lint-changed ✓, typecheck-tsgo ✓. The React Compiler compliance check couldn't run in this environment (it failed to resolve the base branch ref), but the change is a trivial additive prop pass-through with no new hooks or memoization.

Note on verification: this is an Android-native safe-area layout fix (3-button nav bar bottom inset), which doesn't reproduce on the web build, so I didn't run the web tester. Please verify on an Android device per the QA steps in the PR and mark it Ready for review when it looks good.