Background page does not change when navigating to wallet page - #90484
Conversation
Codecov Report❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.
|
|
🚧 @amyevans has triggered a test Expensify/App build. You can view the workflow run here. |
This comment has been minimized.
This comment has been minimized.
|
🚧 @amyevans has triggered a test Expensify/App build. You can view the workflow run here. |
This comment has been minimized.
This comment has been minimized.
|
@ShridharGoel Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| const matchingFullScreenRouteInTabRootState = tabState?.routes?.find((r) => r.name === matchingFullScreenRoute.name); | ||
| if (matchingFullScreenRouteInTabRootState && matchingFullScreenRouteInTabRootState.state === undefined) { | ||
| // First-time visit: initialize the matching tab so its sidebar/split route is added. | ||
| const additionalAction: StackNavigationAction = { |
There was a problem hiding this comment.
❌ CONSISTENCY-3 (docs)
The two branches of the if/else in swapBackgroundTabForRHPTarget construct nearly identical StackNavigationAction objects and both call navigationRef.dispatch(additionalAction). The only difference is how params is computed. This duplication means any future change to the action shape (e.g., adding a new field) must be applied in both branches.
Extract the params computation and consolidate the shared dispatch logic:
const matchingFullScreenRouteInTabRootState = tabState?.routes?.find((r) => r.name === matchingFullScreenRoute.name);
let params: Record<string, unknown>;
if (matchingFullScreenRouteInTabRootState && matchingFullScreenRouteInTabRootState.state === undefined) {
params = {
...(matchingFullScreenRoute.params ?? {}),
...(matchingFullScreenRoute.state ? {state: matchingFullScreenRoute.state} : {}),
};
} else {
const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
params = lastRouteInMatchingFullScreen
? {screen: lastRouteInMatchingFullScreen.name, params: lastRouteInMatchingFullScreen.params}
: matchingFullScreenRoute.params;
}
const additionalAction: StackNavigationAction = {
type: CONST.NAVIGATION.ACTION_TYPE.NAVIGATE,
payload: {
name: matchingFullScreenRoute.name,
params,
},
target: tabNavigatorStateKey,
};
navigationRef.dispatch(additionalAction);Reviewed at: 455e0c7 | Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 455e0c7864
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const targetWillNavigateToRHP = willRouteNavigateToRHP(internalNewExpensifyPath as Route); | ||
| if (!targetWillNavigateToRHP) { | ||
| shouldCloseRHP = true; | ||
| } else { | ||
| // Cross-tab RHP→RHP: swap the background tab in place so the RHP stays mounted and the | ||
| // user sees only the RHP content update + the underlying tab animate, no close+reopen | ||
| // flicker (issue: https://github.com/Expensify/App/issues/89710). | ||
| swapBackgroundTabForRHPTarget(currentState, internalNewExpensifyPath as Route); |
There was a problem hiding this comment.
When a wide-layout RHP is open, this runs the in-app background-tab swap before the later internalNewExpensifyPath && hasSameOrigin check decides whether the URL will actually be handled by Navigation.navigate. For a NewDot RHP URL on a different environment (for example a production new.expensify.com/settings/wallet/... link clicked while using staging/dev), getInternalNewExpensifyPath is non-empty and this can switch the current app’s background tab even though the link then falls through to openExternalLink, leaving the original RHP unexpectedly over a mutated tab. Gate the swap on the same same-origin/internal-navigation condition used before calling Navigation.navigate.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
It is unlikely to hit in practice, but to be safe I've added the else if (hasSameOrigin) gate so the swap only runs when the URL will actually be handled internally. Thanks!
|
Personal card import project, going to swap in Joe. |
joekaufmanexpensify
left a comment
joekaufmanexpensify
left a comment
There was a problem hiding this comment.
Working well!
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / SafariScreen.Recording.2026-05-23.at.11.54.15.PM.mov |
|
🚧 @amyevans has triggered a test Expensify/App build. You can view the workflow run here. |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
|
🚀 Deployed to staging by https://github.com/amyevans in version: 9.3.83-0 🚀
Bundle Size Analysis (Sentry): |
|
I reviewed the changes in this PR. This is a purely internal navigation fix that addresses a UI flicker when navigating between RHP routes that map to different background tabs (e.g., clicking "fix the card" from an expense detail). The changes are:
No help site changes are required. No user-facing features, settings, workflows, button labels, or product behavior were added or modified — this is behind-the-scenes navigation plumbing only. @rinej, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR |
|
🚀 Deployed to production by https://github.com/mountiny in version: 9.3.83-3 🚀
|
7 participants
Explanation of Change
In
openLink(), when the RHP is already open and the target is also an RHP route, we now check whether the target maps to a different background (full-screen) tab than the one currently behind the RHP. If so, we close the current RHP first so the navigation pipeline can set up the correct background tab vialinkTo's full-screen route matching path.The decision is encapsulated in a new helper
willRHPNavigateAcrossBackgroundTabswhich reuses the existinggetMatchingFullScreenRoute+shouldChangeToMatchingFullScreenbuilding blocksFixed Issues
$ #89710
PROPOSAL:
Tests
Video with testing flow -> #89710 (comment)
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari