[Due for payment 2026-06-18] [Due for payment 2026-06-17] [$250] Android & iOS - Report fields - Initial value content overlaps with device status bar

[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.2-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: #91627
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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: Workspace Settings

Action Performed:

1. Launch Expensify app.
2. Go to workspace settings > Reports.
3. Enable Report fields and upgrade workspace if needed.
4. Tap Add field.
5. Tap Type and select List.
6. Tap List values and add a list value.
7. Tap RHP back button.
8. Tap Initial value.

Expected Result:

Initial value content will not overlap with device status bar.

Actual Result:

Initial value content overlaps with device status bar.

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: 7176413

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064687830072139918
• Upwork Job ID: 2064687830072139918
• Last Price Increase: 2026-06-10

[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/8b75e762bc38085820c12cc00b4468d3a8a91bb01e9a5c09331ed1aeeae0e835

[melvin-bot]

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

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

Issue Analysis

Root Cause: The migrated "Initial value" screen explicitly disables the top safe-area inset with includePaddingTop={false}, so on native (Android/iOS) its content renders under the status bar. See DynamicReportFieldsInitialListValuePage.tsx:55-60.

This was introduced by #91627, which migrated InitialListValueSelectorModal (a <Modal>-wrapped component) to a standalone @react-navigation route. The includePaddingTop={false} prop was carried over from the old modal pattern, but it is no longer safe: the old <Modal type={RIGHT_DOCKED}> provided the top inset itself, whereas the new page is a real navigation screen with no Modal wrapper, so nothing supplies the status-bar padding.

Recommended Fix: Remove includePaddingTop={false} from the ScreenWrapper (let it default to true). The sibling RHP route screen ReportFieldsInitialValuePage.tsx:111-116 follows exactly this pattern (default top padding) and renders correctly.

Investigation details

Evidence chain:

• ScreenWrapper's includePaddingTop defaults to true (ScreenWrapper/index.tsx:94) and drives isSafeAreaTopPaddingApplied (index.tsx:135). Setting it to false skips the status-bar inset.
• The still-Modal-based TypeSelectorModal.tsx uses includePaddingTop={false} too, but it is wrapped in <Modal type={CONST.MODAL.MODAL_TYPE.RIGHT_DOCKED}> (TypeSelectorModal.tsx:36-47) — the Modal supplies the inset, so omitting top padding there is correct. The new page dropped the Modal but kept the prop.

Why production isn't affected: This is a brand-new screen shipped in 9.4.2 (staging only); the route did not exist in production, which matches "Reproducible in production?: No."

Alternative considered: A globally broken safe-area provider would affect every RHP screen, but only this newly-migrated page regressed and a sibling screen on the same flow renders fine — pointing squarely at the per-screen includePaddingTop={false} override rather than anything shared.

---

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