[Due for payment 2026-05-11] [Due for payment 2026-05-07] Missing FAB and quick scan after opening report on Home and returning to Inbox

[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.64-18
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #85234
Email or phone of affected tester (no customers): sdsodijnosdjoij@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.3
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create two expenses.
4. Tap app back button.
5. Go to Home tab.
6. Tap Begin button under For you section.
7. Tap report header subtitle link.
8. Tap on the report again.
9. Tap More > Delete > Delete.
10. Tap RHP back button twice.

Expected Result:

FAB and quick scan button will appear on Inbox tab.

Actual Result:

FAB and quick scan button are missing on Inbox after opening report from Home and returning to Inbox.

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: @sumo-slonik

[melvin-bot]

@mountiny recently merged #85234, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @JS00001 (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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: #85234 - "Introduce a Bottom Tab Navigator for Top-Level Navigation" by @WojtekBoman (High confidence)
Related Issues: None

Recommendation: REVERT

PR #85234 introduced a new TabNavigatorBar component with complex visibility/animation logic that controls whether the FAB and quick-scan button are shown. The logic can get into a stuck state after the specific navigation sequence described in the issue, leaving the buttons hidden on the Inbox tab.

Assigned: @WojtekBoman (PR author), @ZhenjaHorbach @mountiny (approving reviewers)
Labels: DeployBlockerCash kept — this is a frontend bug in Expensify/App. No label changes made.

Detailed Analysis

Evidence

• The melvin-bot already linked PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 in the first comment on this issue.
• PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234 ("Introduce a Bottom Tab Navigator for Top-Level Navigation") was merged on 2026-04-24 and is listed in the current StagingDeployCash checklist.
• The bug is reproducible on staging but not on production, which means it was introduced by a PR in the current staging deploy — consistent with PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234.
• The bug involves the FAB (Floating Action Button) and quick-scan camera button disappearing from the Inbox tab after a specific navigation sequence that crosses tabs (Home → report → Inbox).

Verification

• The file src/libs/Navigation/AppNavigator/Navigators/TabNavigatorBar.tsx was introduced by PR Introduce a Bottom Tab Navigator for Top-Level Navigation #85234.
• TabNavigatorBar passes shouldShowFloatingButtons={!isHidden} to NavigationTabBar.
• NavigationTabBar renders <NavigationTabBarFloatingActionButton />, <FloatingGPSButton />, and <FloatingCameraButton /> only when shouldShowFloatingButtons is true (line 278–286 of src/components/Navigation/NavigationTabBar/index.tsx).

Root Cause

TabNavigatorBar.tsx introduced an animation-delay mechanism to prevent the tab bar from flashing when navigating back from a deep screen:

shouldHide = shouldUseNarrowLayout && (!isAtRoot || isBlockingViewVisible)
shouldApplyDelay = !tabChanged && prevShouldHide && !shouldHide
isHidden = shouldHide || (shouldApplyDelay && animationDoneKey !== stateKey)

In the reproduction scenario, the user starts on the Home tab, navigates into a report (causing shouldHide=true), then navigates back to the Inbox tab via a deep RHP navigation path (tapping the report header subtitle, then returning via the RHP back button). During this cross-tab navigation sequence, the tabChanged check (prevTabIndex !== state.index) may not fire or fire at the wrong time — particularly because the navigation passes through the Home tab's report view before landing on Inbox. This can leave shouldApplyDelay=true with the animationDoneKey !== stateKey condition stuck, keeping isHidden=true and hiding the FAB and quick-scan button indefinitely until the app is restarted or navigated in a way that resets the state.

The entire affected file (TabNavigatorBar.tsx) was introduced by PR #85234; reverting it would restore the previous behavior where the FAB visibility was managed separately without this animation-delay logic.