[HOLD for payment 2023-04-07] [HOLD for payment 2023-03-17] Web - Profile - If user deletes the number without validating, page becomes unresponsive

[kbecciv]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

Pre-Condition: User has to validate an account number prior to signing in (You can add a number and then sign out and sign back in)

1. Access staging.new.expensify.com
2. Click on Profile icon (Notice the green dot indicating that the account needs to be validated)
3. Click on Profile > Contact Method > Remove the number (Without validating it)
4. Attempt to close out the page

Expected Result:

User expects to be able to navigate and close the page after deleting the number

Actual Result:

The page freezes and all buttons become unresponsive, the only way to fix this is via refreshing

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome
• MacOS / Desktop

Version Number: 1.2.80.0

Reproducible in staging?: Yes

Reproducible in production?: No

If this was caught during regression testing, add the test name, ID and link from TestRail:

Email or phone of affected tester (no customers):

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Bug5967864_If_user_deletes_a_number_that_needs_to_be_verified_after_signing_in__buttons_dont_respond.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

[kbecciv]

On PROD this has not been implemented yet

Bug5967864_PROD.mp4

[OSBotify]

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

Triggered auto assignment to @aldo-expensify (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[aldo-expensify]

Reproduced in staging with my main account

[aldo-expensify]

Clicking the menu items call the onPress={() => Navigation.navigate(ROUTES.getEditContactMethodRoute(partnerUserID))} just fine, but Navigation.navigate seems to be decided not to do anything:

Screen.Recording.2023-03-08.at.10.55.04.AM.mov

[MelvinBot]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[aldo-expensify]

We are entering here:

and returning early instead of really navigating.

[aldo-expensify]

Navigation.canNavigate is returning false because isNavigating is stuck with true

[aldo-expensify]

The Navigation.isNavigate is being set to true here:

App/src/components/ScreenWrapper/index.js

Lines 41 to 43 in fb20144

	this.unsubscribeTransitionStart = this.props.navigation.addListener('transitionStart', () => {
	Navigation.setIsNavigating(true);
	});

but then the component ScreenWrapper gets unmounted and we unsubscribe to the transition events before processing the 'transitionEnd' event, which would have set Navigation.isNavigating back to false.

I'm not familiarized at all with these transitions and how are the expected to work, so I'll ask. An easy fix would be to set Navigation.isNavigating back to false when we are unsubscribing, but I have no idea if that is a terrible solution.