[Due for payment 2026-10-23] The Receipt Partners invite page bottom padding is too large

@linhvovan29546

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.62-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @linhvovan29546
Slack conversation (hyperlinked to channel name): #Expensify bugs

Action Performed:

Connect to Uber for business from Receipt partners
Open the Receipt partners > Manage invites or
Observe the Invite page once the connection established

Expected Result:

The bottom padding is consistent with other pages.

Actual Result:

The bottom padding is too large

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

Screenshots/Videos

ScreenRecording_08-28-2026.10-09-42_1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mananjadhav

Proposal

What is the root cause of that problem?

The Receipt Partners invite screens keep their ScreenWrapper in legacy safe-area mode while their child SelectionList also opts into bottom safe-area padding, so the safe-area inset gets applied twice at the bottom on native.

ScreenWrapper only disables its own legacy bottom safe-area spacer when enableEdgeToEdgeBottomSafeAreaPadding is passed (ScreenWrapper/index.tsx:138). Neither Receipt Partners page passes it, so ScreenWrapper renders its own bottom inset and the SelectionList adds its own via addBottomSafeAreaPadding. On the Send invites page the effect is worst because the confirmButtonOptions footer (FixedFooter) applies the raw inset regardless of the parent context, stacking pb5 + inset + inset under the confirm button.

This is native-only — web has no safe-area insets, which is exactly why the reporter didn't check Web/mWeb.

Investigation details (high confidence)

Affected files (both introduced in #99638, both missing the prop):

DynamicInviteReceiptPartnerPolicyPage.tsx:214 — "Send invites"; SelectionList has both confirmButtonOptions and addBottomSafeAreaPadding. This is where padding is clearly doubled.
DynamicEditInviteReceiptPartnerPolicyPage.tsx:298 — "Manage invites"; same legacy-mode inconsistency (its SelectionList uses addBottomSafeAreaPadding). It has no footer so its padding self-suppresses to a single inset, but it should still match the reference for consistency.

Mechanism: ScreenWrapper sets includeSafeAreaPaddingBottom = isUsingEdgeToEdgeMode ? false : includeSafeAreaPaddingBottomProp (index.tsx:147). With the prop absent, isUsingEdgeToEdgeMode is false, so the legacy bottom spacer stays on. The FixedFooter used by confirmButtonOptions reads the raw inset via useSafeAreaPaddings(true), which intentionally ignores whether the parent already applied padding — so the two stack.

Known-good reference: the standard workspace member DynamicWorkspaceInvitePage.tsx:252-256 uses the same SelectionList + confirmButtonOptions + addBottomSafeAreaPadding pattern but correctly passes enableEdgeToEdgeBottomSafeAreaPadding, so only one inset is applied. ~28 other selection pages follow this; the two Receipt Partners pages are the outliers.

Alternatives considered: removing addBottomSafeAreaPadding from the SelectionList would also collapse to one inset, but it diverges from the repo-standard pattern and would drop safe-area padding on the scroll area — switching ScreenWrapper to edge-to-edge mode is the change every comparable page makes.

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

Add enableEdgeToEdgeBottomSafeAreaPadding to the <ScreenWrapper> on both pages, matching DynamicWorkspaceInvitePage:

DynamicInviteReceiptPartnerPolicyPage.tsx — both the main return (line 214) and the "All set" branch (line 189).
DynamicEditInviteReceiptPartnerPolicyPage.tsx — line 298.

This puts ScreenWrapper in edge-to-edge mode so the child SelectionList/FixedFooter becomes the single source of bottom safe-area padding.

What alternative solutions did you explore? (Optional)

Removing addBottomSafeAreaPadding from the SelectionList (rejected — diverges from the standard pattern and drops padding on the scrollable area).

💡 Suggested AI code review rule

This looks like a recurring, mechanically detectable edge-to-edge migration mistake (2 outliers vs. ~28 correct pages), so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

Rule: UI-4 — ScreenWrapper must enable edge-to-edge when a child adds bottom safe-area padding
Condition: When a page's SelectionList (or other child) uses addBottomSafeAreaPadding and/or a FixedFooter/confirmButtonOptions, the enclosing ScreenWrapper must pass enableEdgeToEdgeBottomSafeAreaPadding; otherwise the inset is applied twice.
Why: ScreenWrapper keeps its legacy bottom spacer unless it's in edge-to-edge mode, so it stacks with the child's inset → doubled bottom padding on native (mechanism).
Search pattern: files containing addBottomSafeAreaPadding or confirmButtonOptions where the <ScreenWrapper in the same file does not include enableEdgeToEdgeBottomSafeAreaPadding.
Offending code (❌): DynamicInviteReceiptPartnerPolicyPage.tsx:214
Fix (✅): DynamicWorkspaceInvitePage.tsx:252-256

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

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

view run

@mananjadhav

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

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

@mananjadhav

@mananjadhav one heads-up on Melvin's fix before this gets picked up.

The edge-to-edge switch is correct for the SelectionList return, but the proposal also adds it to the "All set" branch (line 189), and that one would break the screen. That branch renders <ConfirmationPage>, whose internal FixedFooter doesn't set addBottomSafeAreaPadding — it relies on ScreenWrapper's legacy bottom inset. Flip it to edge-to-edge and the confirm button loses its bottom padding and sits on the home indicator. That's also why none of the pages using ConfirmationPage are in edge-to-edge mode.

So the change should only go on the SelectionList return (line 214), not the ConfirmationPage branch. The Manage invites page has no footer, so it's already a single inset today — not actually doubled.

Happy to raise a proposal with the exact diff if that helps.

@mananjadhav

@mananjadhav Whoops! This issue is 2 days overdue. Let's get this updated quick!

@yusufdeveloper2903

@yusufdeveloper2903's proposal seems good here.

🎀 👀 🎀 C+ reviewed.

@NicolasBonet

Triggered auto assignment to @NicolasBonet, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

@mananjadhav

@mananjadhav

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.5.12-1 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

Stop doubling the bottom safe area padding on the Uber send invites page #103296

If no regressions arise, payment will be issued on 2026-10-23. 🎊

The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the Contributor+ Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]

Not overdue

@mananjadhav

@mananjadhav Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

Navigation Menu

Repository navigation

[Due for payment 2026-10-23] The Receipt Partners invite page bottom padding is too large #99763

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

💡 Suggested AI code review rule

53 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-10-23] The Receipt Partners invite page bottom padding is too large #99763

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

MelvinBot commented on Aug 28, 2026

Proposal

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

💡 Suggested AI code review rule

melvin-bot commented on Aug 28, 2026

melvin-bot commented on Aug 28, 2026

David-2002065 commented on Aug 30, 2026

melvin-bot commented on Aug 31, 2026

mananjadhav commented on Sep 2, 2026

melvin-bot commented on Sep 2, 2026

53 remaining items

melvin-bot commented on Oct 16, 2026

NicolasBonet commented on Oct 19, 2026

melvin-bot commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions