[$250] Home - Click on Add address not navigate to Wallet

[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.58-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/40579099/test-cases/88865976
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: -
App Component: Other

Action Performed:

Precondition: physical E card without address assigned.

1. Go to Home tab
2. Click on Add address button in Time sensitive section

Expected Result:

User navigated to Account > Wallet > Expensify Card

Actual Result:

User stays on Home page

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042648234326414633
• Upwork Job ID: 2042648234326414633
• Last Price Increase: 2026-04-10

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

BaseWidgetItem (src/components/BaseWidgetItem.tsx:49-80) wraps an outer PressableWithoutFeedback and an inner Button, both bound to the same onCtaPress handler. On web, React Native Web's PressResponder calls event.stopPropagation() on click (PressResponder.js:429), so clicking the Button fires onCtaPress once while preventing the outer press — and clicking the icon/text area fires the outer onCtaPress once.

However, there is an important interaction: the outer PressableWithoutFeedback (role="button") captures the responder on pointerdown, which happens before the inner Button's click event. When the outer element becomes the active responder, it calls onResponderRelease → onPressOut flow, but PressResponder fires onPress only from the click handler — not from the responder release. Meanwhile, the outer element's onClick handler runs with stopPropagation, meaning the inner Button's onClick never fires at all when the outer PressableWithoutFeedback wins the responder race.

The net effect: the onCtaPress callback runs via the outer PressableWithoutFeedback only. The PressableWithoutFeedback has onPress={onCtaPress} at line 51, which calls Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD.getRoute(String(card.cardID))). This navigation call reaches linkTo which generates a PUSH action for RIGHT_MODAL_NAVIGATOR. The push should work, but because shouldChangeToMatchingFullScreen returns false when the current fullscreen is HOME (linkTo/index.ts:100-101), the Settings fullscreen is not pushed underneath the RHP overlay. The RHP opens over HOME directly. If this code path has a rendering or state initialization issue (e.g., the Settings RHP navigator expects its parent fullscreen to be in the stack), the RHP could open empty or fail to mount.

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

Restructure BaseWidgetItem to use a single interactive element instead of nesting two:

1. Remove onPress from the outer PressableWithoutFeedback — keep it only for hover styling (rename to a non-interactive View with hover via Hoverable, or use Pressable with onPress={undefined})
2. Keep onPress only on the inner Button — this is the visible CTA and should be the sole press target
3. Alternatively, remove the inner Button's onPress and let the outer Pressable handle all presses — but style the Button as visual-only

This eliminates the nested interactive element conflict. The outer element provides hover feedback for the row; the inner Button handles navigation.

What alternative solutions did you explore? (Optional)

• Adding e.stopPropagation() manually in the Button's onPress — this is already done by PressResponder but the responder system still creates the conflict
• Using pointerEvents="box-none" on the outer Pressable to let events pass through to children — this would break the row-wide hover effect
• Wrapping the navigation call in setNavigationActionToMicrotaskQueue (like GettingStartedRow does) to delay it past any responder cleanup — this is a workaround, not a fix

Investigation details

Code path traced:

1. AddShippingAddress.tsx:26 → onCtaPress calls Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD.getRoute(String(card.cardID)))
2. Navigation.ts:335 → calls linkTo(navigationRef.current, targetRoute)
3. linkTo/index.ts:148 → dedup check passes (not already on this route)
4. linkTo/index.ts:166 → action type changed to PUSH
5. linkTo/index.ts:176 → shouldChangeToMatchingFullScreen returns false (HOME special case)
6. linkTo/index.ts:192 → dispatches PUSH for RIGHT_MODAL_NAVIGATOR

Confirmed not the issue:

• Route configuration is correct (settings/wallet/card/:cardID? → ExpensifyCardPage)
• Navigation guards (OnboardingGuard, MigratedUserWelcomeModalGuard) allow this action for normal users
• Button is not disabled (buttonProps={{success: true}} only sets color)
• card.cardID is a valid number from CARD_LIST Onyx key
• No redirects apply to this route path

Other BaseWidgetItem consumers affected: All TimeSensitiveSection items use BaseWidgetItem — ValidateAccount, FixCompanyCardConnection, ActivateCard, etc. If this is a BaseWidgetItem-level issue, all of these would be broken. AssignedCardsSection uses MenuItemWithTopDescription (single Pressable) and navigates to the same route, so it can be used to verify the route works independently.

---

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.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @DylanDylann (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022042648234326414633

[twilight2294]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Clicking "Add address" in the Home page's Time Sensitive section does not navigate the user to the address form — it appears to do nothing or lands on the wrong screen.

What is the root cause of that problem?

The onCtaPress handler in AddShippingAddress navigates to the wrong route:

onCtaPress={() => Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAIN_CARD.getRoute(String(card.cardID)))}

SETTINGS_WALLET_DOMAIN_CARD resolves to settings/wallet/card/:cardID — the card details page in the Settings central pane. Since the user is on the Home tab, this navigation doesn't surface the address form. The correct route is SETTINGS_DOMAIN_CARD_UPDATE_ADDRESS (settings/card/:cardID/update-address), which opens the address update form in the RHP modal. This is the same route the card details page itself uses when the user taps "Update address" from within Settings.

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

In AddShippingAddress, change the navigation target:

onCtaPress={() => Navigation.navigate(ROUTES.SETTINGS_DOMAIN_CARD_UPDATE_ADDRESS.getRoute(String(card.cardID)))}

One-line fix. SETTINGS_DOMAIN_CARD_UPDATE_ADDRESS is already defined in ROUTES, wired in the linking config, and registered in the modal stack navigator.

What alternative solutions did you explore? (Optional)

This differs from MelvinBot's proposal in root cause and fix. MelvinBot attributes the bug to nested Pressable/Button responder conflicts in BaseWidgetItem and proposes restructuring that component. The actual problem is simpler: the navigation target is wrong. The button fires fine — it just navigates to the card details page instead of the address form. Restructuring BaseWidgetItem would not fix the navigation to the wrong route, and is an unnecessary refactor that risks regressions across all widgets using that component.

[abbasifaizan70]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-15 11:55:33 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

Clicking "Add address" in the Home page's Time Sensitive section does not navigate the user to the address form — it appears to do nothing or lands on the wrong screen.

What is the root cause of that problem?

Runtime RHP navigation depends on linkTo() inserting/updating the fullscreen route under the overlay. For /settings/wallet/card/:cardID, a matching Settings fullscreen route is correctly computed, but the previous logic intentionally skipped fullscreen changes when the currently visible fullscreen was HOME.
Because of that skip, the RHP opens while the center pane remains Home.

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 91 to 112 in 808703d

	function shouldChangeToMatchingFullScreen(
	newFocusedRoute: ReturnType<typeof findFocusedRoute>,
	matchingFullScreenRoute: NavigationPartialRoute,
	lastFullScreenRoute: NavigationPartialRoute,
	) {
	if (matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
	// HOME has no RHP children (HOME_TO_RHP maps to []).
	// Pushing another fullscreen under HOME causes Android to trim HOME
	// from the render tree, reversing the back animation direction.
	if (lastFullScreenRoute.name === SCREENS.HOME) {
	return false;
	}
	return true;
	}
	const lastRouteInLastFullScreenRoute = lastFullScreenRoute?.state?.routes.at(-1);
	// We always want the fullscreen route of SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD to be the SUBSCRIPTION tab of SCREENS.SETTINGS.
	// The add payment card page can be opened via the Global create button from the create expense flow, so even when we are already on SCREENS.SETTINGS, with any tab currently open,
	// the add payment card page can still be opened. Therefore, checking only the fullscreen name above is not sufficient, and the check below using the last route name is necessary.
	return newFocusedRoute?.name === SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD && lastRouteInLastFullScreenRoute?.name !== SCREENS.SETTINGS.SUBSCRIPTION.ROOT;
	}

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 169 to 187 in 808703d

	// If we deep link to a RHP page, we want to make sure we have the correct full screen route under the overlay.
	if (shouldCheckFullScreenRouteMatching(action)) {
	const newFocusedRoute = findFocusedRoute(stateFromPath);
	if (newFocusedRoute) {
	const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);
	const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
	if (matchingFullScreenRoute && lastFullScreenRoute && shouldChangeToMatchingFullScreen(newFocusedRoute, matchingFullScreenRoute, lastFullScreenRoute as NavigationPartialRoute)) {
	if (isRoutePreloaded(currentState, matchingFullScreenRoute)) {
	navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
	} else {
	const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
	const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
	screen: lastRouteInMatchingFullScreen?.name,
	params: lastRouteInMatchingFullScreen?.params,
	});
	navigation.dispatch(additionalAction);
	}
	}

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

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 91 to 112 in 808703d

	function shouldChangeToMatchingFullScreen(
	newFocusedRoute: ReturnType<typeof findFocusedRoute>,
	matchingFullScreenRoute: NavigationPartialRoute,
	lastFullScreenRoute: NavigationPartialRoute,
	) {
	if (matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
	// HOME has no RHP children (HOME_TO_RHP maps to []).
	// Pushing another fullscreen under HOME causes Android to trim HOME
	// from the render tree, reversing the back animation direction.
	if (lastFullScreenRoute.name === SCREENS.HOME) {
	return false;
	}
	return true;
	}
	const lastRouteInLastFullScreenRoute = lastFullScreenRoute?.state?.routes.at(-1);
	// We always want the fullscreen route of SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD to be the SUBSCRIPTION tab of SCREENS.SETTINGS.
	// The add payment card page can be opened via the Global create button from the create expense flow, so even when we are already on SCREENS.SETTINGS, with any tab currently open,
	// the add payment card page can still be opened. Therefore, checking only the fullscreen name above is not sufficient, and the check below using the last route name is necessary.
	return newFocusedRoute?.name === SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD && lastRouteInLastFullScreenRoute?.name !== SCREENS.SETTINGS.SUBSCRIPTION.ROOT;
	}

function shouldChangeToMatchingFullScreen(
    newFocusedRoute: ReturnType<typeof findFocusedRoute>,
    matchingFullScreenRoute: NavigationPartialRoute,
    lastFullScreenRoute: NavigationPartialRoute,
) {
    if (matchingFullScreenRoute.name !== lastFullScreenRoute.name) {
        return true;
    }

    const lastRouteInLastFullScreenRoute = lastFullScreenRoute?.state?.routes.at(-1);

    return newFocusedRoute?.name === SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD && lastRouteInLastFullScreenRoute?.name !== SCREENS.SETTINGS.SUBSCRIPTION.ROOT;
}

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 169 to 187 in 808703d

	// If we deep link to a RHP page, we want to make sure we have the correct full screen route under the overlay.
	if (shouldCheckFullScreenRouteMatching(action)) {
	const newFocusedRoute = findFocusedRoute(stateFromPath);
	if (newFocusedRoute) {
	const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);
	const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
	if (matchingFullScreenRoute && lastFullScreenRoute && shouldChangeToMatchingFullScreen(newFocusedRoute, matchingFullScreenRoute, lastFullScreenRoute as NavigationPartialRoute)) {
	if (isRoutePreloaded(currentState, matchingFullScreenRoute)) {
	navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
	} else {
	const lastRouteInMatchingFullScreen = matchingFullScreenRoute.state?.routes?.at(-1);
	const additionalAction = StackActions.push(matchingFullScreenRoute.name, {
	screen: lastRouteInMatchingFullScreen?.name,
	params: lastRouteInMatchingFullScreen?.params,
	});
	navigation.dispatch(additionalAction);
	}
	}

if (shouldCheckFullScreenRouteMatching(action)) {
    const newFocusedRoute = findFocusedRoute(stateFromPath);
    if (newFocusedRoute) {
        const matchingFullScreenRoute = getMatchingFullScreenRoute(newFocusedRoute);

        const lastFullScreenRoute = currentState.routes.findLast((route) => isFullScreenName(route.name));
        if (matchingFullScreenRoute && lastFullScreenRoute && shouldChangeToMatchingFullScreen(newFocusedRoute, matchingFullScreenRoute, lastFullScreenRoute as NavigationPartialRoute)) {
            const fullScreenParams = getFullScreenNavigationParams(matchingFullScreenRoute);

            if (lastFullScreenRoute.name === SCREENS.HOME) {
                navigation.dispatch({
                    ...StackActions.replace(matchingFullScreenRoute.name, fullScreenParams),
                    source: lastFullScreenRoute.key,
                    target: currentState.key,
                });
            } else if (isRoutePreloaded(currentState, matchingFullScreenRoute)) {
                navigation.dispatch(StackActions.push(matchingFullScreenRoute.name));
            } else {
                const additionalAction = StackActions.push(matchingFullScreenRoute.name, fullScreenParams);
                navigation.dispatch(additionalAction);
            }
        }
    }
}

[github-actions]

⚠️ @abbasifaizan70 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[HamzaSwitch]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @HamzaSwitch Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.