[Due for payment 2026-05-13] Expense - Blank space is shown below Save button in Add category page

[jponikarchuk]

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.3.67-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: #86177
Email or phone of affected tester (no customers): josdjnosdjionjsdonjisod@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. Go to workspace chat.
3. Create a manual expense.
4. Open expense report.
5. Click Category.
6. Click + button.
7. Close the keyboard.

Expected Result:

There will be no blank space below Save button.

Actual Result:

Blank space is shown below Save button.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ahmedGaber93

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #86177 - "Feat: add a new category within the category list" by @daledah (High confidence)
Related Issues: #85681

Recommendation: REVERT

PR #86177 introduced a new screen (IOURequestStepCategoryCreate) that shows a blank space below the Save button after the keyboard is dismissed on mobile (Android and iOS). This is a UI layout regression introduced directly by this PR, and reverting it is the cleanest fix.

Assigned: @daledah (PR author), @ahmedGaber93 (approving reviewer), @amyevans (approving reviewer)
Labels: No label changes needed — DeployBlockerCash is correctly applied (this is a Frontend/App bug on staging only, not present in production)

Detailed Analysis

Evidence

• The melvin-bot automatically identified PR Feat: add a new category within the category list #86177 as the cause and assigned its author.
• The bug is reproducible on staging (version 9.3.67-0) only — described as a new feature not yet in production.
• PR Feat: add a new category within the category list #86177 is listed in the StagingDeployCash checklist for this release.
• The issue steps (create expense > open Category > click + button > close keyboard > blank space below Save) exactly match the new feature added by this PR: the "+" button to create a new category inline within the IOU flow.

Verification

• The PR added src/pages/iou/request/step/IOURequestStepCategoryCreate.tsx — the new screen that renders when the "+" button is tapped.
• This new screen uses StepScreenWrapper wrapping CategoryForm. The CategoryForm uses addBottomSafeAreaPadding on FormProvider.
• The equivalent workspace CreateCategoryPage (which works correctly) uses ScreenWrapper with enableEdgeToEdgeBottomSafeAreaPadding and shouldEnableMaxHeight={true}, while StepScreenWrapper does not pass enableEdgeToEdgeBottomSafeAreaPadding.
• This mismatch causes the bottom safe-area / keyboard-avoidance padding not to collapse correctly after the keyboard is dismissed, leaving a blank space below the Save button.
• Affected files from the PR: IOURequestStepCategoryCreate.tsx (new file), StepScreenWrapper.tsx (modified).

Root Cause

StepScreenWrapper does not forward enableEdgeToEdgeBottomSafeAreaPadding to its inner ScreenWrapper. When CategoryForm is rendered inside this wrapper with addBottomSafeAreaPadding, the safe-area padding logic in FormWrapper adds bottom padding that does not shrink when the keyboard is dismissed, resulting in a persistent blank space below the Save button on touch-screen devices.

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Add Category" page (IOURequestStepCategoryCreate.tsx) renders inside StepScreenWrapper, which uses legacy safe-area mode — it passes includeSafeAreaPaddingBottom to ScreenWrapper but does not pass enableEdgeToEdgeBottomSafeAreaPadding. This makes the container apply bottom safe-area padding and sets isSafeAreaBottomPaddingApplied=true in context.

Meanwhile, CategoryForm passes addBottomSafeAreaPadding to FormProvider, which triggers edge-to-edge mode inside FormWrapper. In edge-to-edge mode, useSafeAreaPaddings(true) bypasses the context check and returns the full paddingBottom value — adding bottom safe-area padding a second time to the ScrollView content.

The result is double bottom safe-area padding. While the keyboard is open it masks the extra space; once dismissed, the blank space becomes visible.

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

Remove addBottomSafeAreaPadding from CategoryForm when it's rendered inside IOURequestStepCategoryCreate, since StepScreenWrapper already handles bottom safe-area padding in legacy mode.

Concretely, IOURequestStepCategoryCreate should pass a prop (e.g., addBottomSafeAreaPadding={false}) to CategoryForm, and CategoryForm should forward it to FormProvider instead of hardcoding addBottomSafeAreaPadding. This keeps the existing CreateCategoryPage (workspace settings path) working correctly — it uses ScreenWrapper with enableEdgeToEdgeBottomSafeAreaPadding directly, so it needs the prop.

What alternative solutions did you explore? (Optional)

An alternative would be to add enableEdgeToEdgeBottomSafeAreaPadding support to StepScreenWrapper and pass includeSafeAreaPaddingBottom={false}, switching the wrapper to edge-to-edge mode. However, this has a wider blast radius since StepScreenWrapper is used by many other step pages, and the simpler per-consumer opt-out is safer for a deploy blocker fix.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.