[Due for payment 2026-03-19] Expense - Sluggish animation when RHP closes

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.36-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: #82510
Email or phone of affected tester (no customers): sdoijsdniojsodsjodsjis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Go to staging.new.expensify.com
Go to workspace chat.
Create two expenses.
Open the report.
Open any expense.
Click Amount.
Click outside the RHP.
Repeat Step 6 and 7.

Expected Result:

RHP will close smoothly.

Actual Result:

RHP closes sluggishly.

This issue happens with other RHP such as report details RHP.

Workaround:

Unknown

Platforms:

Screenshots/Videos

Bug7100468_1773266389761.16.mp4

View all open jobs on GitHub

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

💬 A slack conversation has been started in #expensify-open-source

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

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

@TaduJR

Investigation Summary

Classification: Frontend bug
Causing PR: #82510 - "fix: Screen Reader: Many Pages: There is no dialog role and title announced" by @TaduJR (High confidence)
Related Issues: #84958, #84966, #85007 (all caused by same PR)

Recommendation: REVERT (already in progress via #84967)

The revert PR is already open and addresses multiple deploy blockers caused by the same root cause. PR #82510 introduced DialogLabelContext and focus management hooks that interfere with RHP animations.

Labels: This issue should KEEP the DeployBlockerCash label as it is a frontend (App) bug that blocks the mobile deploy. A revert PR (#84967) is already open to address this and related issues.

Detailed Analysis

Evidence

PR #82510 was merged on 2026-03-11 (position 75 in the StagingDeployCash checklist) and introduced accessibility improvements for screen readers. The PR added:

DialogLabelContext with state management
useDialogTitleFocus hook that listens to navigation transitionEnd events
Multiple useEffect hooks in the Header component
Focus management that runs on every RHP interaction

The issue reports sluggish RHP closing animation, reproducible in staging but NOT in production. This timing aligns perfectly with PR #82510 being on staging but not production.

Verification

Files modified by PR #82510 that are directly related to RHP rendering:

/home/runner/_work/App/App/src/components/Header.tsx - Added focus management hooks
/home/runner/_work/App/App/src/hooks/useDialogTitleFocus/index.ts - New hook that listens to transitionEnd events
/home/runner/_work/App/App/src/components/DialogLabelContext.tsx - New context with state updates
/home/runner/_work/App/App/src/libs/Navigation/AppNavigator/Navigators/RightModalNavigator.tsx - Wrapped Stack.Navigator with new providers

Root Cause

The sluggish animation is caused by performance overhead from:

DialogLabelContext state updates: The context creates new objects on every render (actions and value objects are not memoized), causing unnecessary re-renders throughout the RHP component tree.
Focus management interference: The useDialogTitleFocus hook listens to the transitionEnd navigation event. Even when closing the RHP, this event handler is active and attempts to focus the title element, potentially interfering with the closing animation.
Multiple useEffect hooks: The Header component now runs 3 useEffect hooks on every RHP interaction (label registration, focus management, and cleanup), adding computational overhead during transitions.

The performance impact manifests as sluggish animations because these operations occur during the critical animation frame period when the RHP is transitioning closed.

Revert Status

A revert PR (#84967) has already been created by @amyevans and is open for review. It addresses this issue along with three other deploy blockers (#84958, #84966, #85007) caused by the same PR.

@mitarachim

Note: This issue currently has both DeployBlockerCash and DeployBlocker labels. Since this is a Frontend bug (caused by App PR #82510), it should only have DeployBlockerCash to block the App deploy. However, both labels were added by an internal employee (@mitarachim), so per protocol I am not removing any labels. An internal team member should review and remove the DeployBlocker label if appropriate.

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.