[$500] Tapping on back arrow in the thread takes user to LHN instead of the parent message

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.4.38-0
Reproducible in staging?: y
Reproducible in production?: y
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
Expensify/Expensify Issue URL:
Issue reported by: @quinthar
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1707282748260789

Action Performed:

1. Open any report
2. Long press and start thread
3. send a message
4. Tap back arrow

Expected Result:

Taking user to parent message

Actual Result:

Takes user to LHN

Workaround:

unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

az_recorder_20240207_110102.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a2adb75f9035e2a6
• Upwork Job ID: 1755260136545419264
• Last Price Increase: 2024-02-07

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[ZhenjaHorbach]

Proposal

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

Tapping on back arrow in the thread takes user to LHN instead of the parent message

What is the root cause of that problem?

The main problem with this issue is that when we press back we always return to Home on Report screen page

App/src/pages/home/ReportScreen.js

Lines 289 to 291 in 04795f9

	const goBack = useCallback(() => {
	Navigation.goBack(ROUTES.HOME, false, true);
	}, []);

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

To fix this issue we can update this function and add new condition

    const isThread = ReportUtils.isChatThread(report);
    const goBack = useCallback(() => {
        if (isThread) {
            Navigation.goBack();
            return;
        }
        Navigation.goBack(ROUTES.HOME, false, true);
    }, [isThread]);

Also, we can make these changes optional for small screens
But I'm not sure that it makes sense

What alternative solutions did you explore? (Optional)

NA

[allgandalf]

Proposal

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

Tapping on back arrow in the thread takes user to LHN instead of the parent message

What is the root cause of that problem?

We reroute all type of ReportScreen views to HOME

App/src/pages/home/ReportScreen.js

Lines 289 to 291 in 04795f9

	const goBack = useCallback(() => {
	Navigation.goBack(ROUTES.HOME, false, true);
	}, []);

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

Reroute all goBack calls to their respective routes:

 const goBack = useCallback(() => { 
     Navigation.goBack(); 
 }, []); 

What alternative solutions did you explore? (Optional)

N/A

[FitseTLT]

Proposal

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

Tapping on back arrow in the thread takes user to LHN instead of the parent message

What is the root cause of that problem?

This is a regression caused by recent changes (Ideal Nav) #33280 of setting the ROUTES.HOME from empty string to Home now.
So before this change when we goBack with ROUTES.HOME as fallback Navigation.goBack(ROUTES.HOME, false, true); b/c home is empty string it will falsify this

App/src/libs/Navigation/Navigation.ts

Lines 229 to 230 in f6ba751

	if (isCentralPaneFocused && fallbackRoute && distanceFromPathInRootNavigator > 0) {
	navigationRef.current.dispatch(StackActions.pop(distanceFromPathInRootNavigator));

So whenever possible it will navigationRef.current.goBack so it worked fine

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

Now everywhere we are calling Navigation.goBack(ROUTES.HOME, false, true); it is not working right so we have to change in
Navigation.goBack everywhere we used fallbackRoute as a condition we need to check it is not ROUTES.HOME here and here

fallbackRoute && fallbackRoute !== ROUTES.HOME

Or similarly everywhere in the codebase we are using ROUTES.HOME as a fallbackRoute we need to pass empty string to revert back the previous behaviour

What alternative solutions did you explore? (Optional)

[Santhosh-Sellavel]

Unassiging this one due to low bandwidth, please reassign @garrettmknight!

[situchan]

This should be part of #35626

[situchan]

@adamgrzybowski please confirm that your PR fixes this as well

[hayata-suenaga]

this issue is tracked in this GH issue. Closing this one 🙇