[$500] Request Money - [Scan receipt] Compose box is not focused when visiting requested money details chat after deleting another one

[izarutskaya]

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:

1. Open website
2. Click on + icon
3. Request Money
4. Choose Scan, file and user
5. Click on Request btn
6. Reach "Receipt scan in progress" chat and delete it
7. Visit another "Receipt scan in progress" chat

Expected Result:

Compose box should be focused when visiting requested money details chat after deleting another one

Actual Result:

Compose box is not focused when visiting requested money details chat after deleting another one

Workaround:

Unknown

Platforms:

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

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

Version Number: v1.3.68-12

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

Notes/Photos/Videos: Any additional supporting documentation

Screen-Capture.-.2023-08-29T203858.242.1.mp4

Recording.1515.mp4

Expensify/Expensify Issue URL:

Issue reported by: @MahmudjonToraqulov

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693323530864789

View all open jobs on GitHub

Actual Result:

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a4ca96d5c6ee6b8d
• Upwork Job ID: 1702371901400743936
• Last Price Increase: 2023-09-21

[DylanDylann]

Proposal

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

• Compose box is not focused when visiting requested money details chat after deleting another one

What is the root cause of that problem?

• This bug occurs with the case manual request as well.
• Below are the main steps occurs when deleting request money and visit another one:

1. When opening the TransactionThread and clicking on the "Delete Request" button, it will open the confirm modal and set the modal.isVisible to true. (ONYXKEYS.MODAL)
2. After clicking the "Delete" button in the confirm modal, it will navigate the user to the previous report screen without setting the modal.isVisible to true because the modal is unmounted before the onModalHide function (which will set the modal.isVisible to false) is called:
   

   App/src/components/MoneyRequestHeader.js

   Lines 70 to 73 in a2d71a3

   	const deleteTransaction = useCallback(() => {
   	IOU.deleteMoneyRequest(parentReportAction.originalMessage.IOUTransactionID, parentReportAction, true);
   	setIsDeleteModalVisible(false);
   	}, [parentReportAction, setIsDeleteModalVisible]);

3. The modal.isVisible is used to check whether we should run the focus function or not:
   

   App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions.js

   Lines 422 to 435 in 7f5c14a

   	useEffect(() => {
   	if (modal.isVisible && !prevIsModalVisible) {
   	// eslint-disable-next-line no-param-reassign
   	isNextModalWillOpenRef.current = false;
   	}
   	// We want to focus or refocus the input when a modal has been closed or the underlying screen is refocused.
   	// We avoid doing this on native platforms since the software keyboard popping
   	// open creates a jarring and broken UX.
   	if (!(willBlurTextInputOnTapOutside && !isNextModalWillOpenRef.current && !modal.isVisible && isFocused && (prevIsModalVisible || !prevIsFocused))) {
   	return;
   	}
   	focus();
   	}, [focus, prevIsFocused, prevIsModalVisible, isFocused, modal.isVisible, isNextModalWillOpenRef]);

4. Because the modal.isVisible is still true, visiting another one will not auto focus on the composer

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

• We should set the Modal.isvisible to false before navigation actions like below:

function deleteMoneyRequest(transactionID, reportAction, isSingleTransactionView = false) {
...
 Modal.setModalVisibility(false);
    if (isSingleTransactionView && shouldDeleteTransactionThread && !shouldDeleteIOUReport) {
        // Pop the deleted report screen before navigating. This prevents navigating to the Concierge chat due to the missing report.
        Navigation.goBack();
        Navigation.navigate(ROUTES.getReportRoute(iouReport.reportID));
        return;
    }

    if (shouldDeleteIOUReport) {
        // Pop the deleted report screen before navigating. This prevents navigating to the Concierge chat due to the missing report.
        Navigation.goBack();
        Navigation.navigate(ROUTES.getReportRoute(iouReport.chatReportID));
    }
}

What alternative solutions did you explore? (Optional)

• NA

Result

Screencast.from.11-09-2023.22.41.13.webm

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[sakluger]

I reproduced this and do think it's a bug. Here's what I notice:

• When I click into the User a owes $X thread from a DM chat, the compose box is focused/highlighted by default
• When I click into an IOU or manual request (I.e. receipt scan in progress) from the User a owes $X thread, the compose box is unfocused by default (this is expected)
• When I click back out to the User a owes $X thread via the "From" link at the top of the page, the compose box is focused (expected)
• When I click back into the User a owes $X thread, then click into an IOU or manual request and delete that IOU/manual request, it brings me back to the User a owes $X thread with the compose box unfocused (not expected behavior).

[melvin-bot]

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

[melvin-bot]

Current assignee @sakluger is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[sakluger]

@0xmiroslav could you please have a look at the proposal we got last week? Thanks!

[0xmiros]

@DylanDylann thanks for the proposal, but the solution doesn't fix the root cause if your analysis is correct.

without setting the modal.isVisible to true because the modal is unmounted before the onModalHide function (which will set the modal.isVisible to false) is called

[DylanDylann]

@0xmiroslav why not? Please give me more details. Thanks

[0xmiros]

Please try to find general solution. Let's fix this in modal. Delete request case is just one example of this issue.

[DylanDylann]

@0xmiroslav currently we have cleanup function when the modal is unmount:

App/src/components/Modal/BaseModal.js

Lines 85 to 98 in 4d97719

	useEffect(
	() => () => {
	// Only trigger onClose and setModalVisibility if the modal is unmounting while visible.
	if (isVisible) {
	hideModal(true);
	Modal.willAlertModalBecomeVisible(false);
	}
	// To prevent closing any modal already unmounted when this modal still remains as visible state
	Modal.setCloseModal(null);
	},
	// eslint-disable-next-line react-hooks/exhaustive-deps
	[],
	);

• After clicking on the confirm button and navigating to previous report, this cleanup function is called but the isVisible is always false so the hideModal is not called. So we can fix this by adding the isVisible to the dependences
• The above is the general solution and applied for the modal

[melvin-bot]

@sakluger, @0xmiroslav Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[0xmiros]

After clicking on the confirm button and navigating to previous report, this cleanup function is called but the isVisible is always false so the hideModal is not called. So we can fix this by adding the isVisible to the dependences

@DylanDylann can you please share video to verify your fix?

[DylanDylann]

@0xmiroslav Please help check this video

Screencast.from.21-09-2023.23.54.26.webm

[sakluger]

Chill out Melvin, we're working on this one.

[0xmiros]

@DylanDylann your solution was deprecated in #27639.
Please update proposal

[DylanDylann]

@0xmiroslav Maybe this issue has been fixed. Can not reproduce this now

[0xmiros]

I am also not able to reproduce.
@sakluger let's close

[melvin-bot]

@sakluger, @0xmiroslav Whoops! This issue is 2 days overdue. Let's get this updated quick!

[sakluger]

Okay, thanks you two. Closing.