mWeb - Reports - Empty state screen shown with "0 selected" behind when deleting expenses

[lanitochka17]

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: 9.0.87-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5479455&group_by=cases:section_id&group_order=asc&group_id=319502
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the staging.new.expensify.com website
2. Log in with an account that already contains expenses or create a few
3. Tap on "Reports" on the bottom of the screen
4. Select all the expenses
5. Tap on the green dropdown menu and select "Delete Expenses"
6. Check if empty state screen is displayed without the dropdown menu on the background and can´t be scrolled
7. Check if "Create Expense" button is displayed with the empty state screen

Expected Result:

Empty state screen, should be displayed without any content on the background and the "Create Expense" button should be displayed with it

Actual Result:

When deleting all the expenses, empty state screen appears with the green dropdown menu with the message "0 selected" on the background, it can be scrolled and the "Create Expense" button is not automatically displayed on it

Workaround:

Unknown

Platforms:

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

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6717309_1737176377563.Empty.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @stephanieelliott (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[Shahidullah-Muffakir]

I think this will be addressed here #54485

[bernhardoj]

Proposal

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

The selection mode is still on after deleting all expenses.

What is the root cause of that problem?

We already have a logic to turn off the selection if the result is empty.

App/src/components/Search/index.tsx

Lines 299 to 304 in 1466369

	useEffect(() => {
	if (!isSearchResultsEmpty || prevIsSearchResultEmpty) {
	return;
	}
	turnOffMobileSelectionMode();
	}, [isSearchResultsEmpty, prevIsSearchResultEmpty]);

When we delete the expenses, we first trigger the API and delay clearing the selection.

App/src/components/Search/SearchPageHeader.tsx

Lines 97 to 103 in 1466369

	deleteMoneyRequestOnSearch(hash, selectedTransactionsKeys);
	// Translations copy for delete modal depends on amount of selected items,
	// We need to wait for modal to fully disappear before clearing them to avoid translation flicker between singular vs plural
	InteractionManager.runAfterInteractions(() => {
	clearSelectedTransactions();
	});

This will trigger the useEffect above toggling the selection mode off. However, we also have another effect that toggle the selection mode on if it's currently off but the selected items are not empty.

App/src/components/Search/index.tsx

Lines 169 to 172 in 1466369

	if (selectedKeys.length > 0 && !selectionMode?.isEnabled) {
	turnOnMobileSelectionMode();
	}
	}, [isSmallScreenWidth, selectedTransactions, selectionMode?.isEnabled]);

So, the selection is toggled on back.

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

We need to "delay" both clearing the selection and the delete calls. Somehow it doesn't work if I put both of the calls inside interactionmanager, so I decided to do it inside onModalHide which also accurately tells whether the modal is hidden or not. To do this, first we need to create a new ref called isDeleteAfterModalHide.

When deleting the expenses, set isDeleteAfterModalHide to true.

isDeleteAfterModalHide.current = true;
setIsDeleteExpensesConfirmModalVisible(false);

Then, inside the onModalHide, if isDeleteAfterModalHide is true, then we clears the selection and calls the API.

App/src/components/Search/SearchPageHeader.tsx

Lines 326 to 331 in 1466369

	<ConfirmModal
	isVisible={isDeleteExpensesConfirmModalVisible}
	onConfirm={handleDeleteExpenses}
	onCancel={() => {
	setIsDeleteExpensesConfirmModalVisible(false);
	}}

onModalHide={() => {
    if (!isDeleteAfterModalHide.current) {
        return;
    }
    clearSelectedTransactions();
    deleteMoneyRequestOnSearch(hash, selectedTransactionsKeys);
    isDeleteAfterModalHide.current = false;
}}

There are 2 delete confirmation modals, 1 for narrow layout, 1 for large layout. We need to create a function for the modal hide logic so we can reuse it for both modals.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

[truph01]

Proposal

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

• When deleting all the expenses, empty state screen appears with the green dropdown menu with the message "0 selected" on the background, it can be scrolled and the "Create Expense" button is not automatically displayed on it.

What is the root cause of that problem?

• We already have a function to turn off selection mode if the selected options is empty:
  

  App/src/components/Search/index.tsx

  Line 303 in 1466369

  turnOffMobileSelectionMode();

but after that, we call the function to turn on selection mode again because the selectedTransactions update occurs with a delay:

App/src/components/Search/index.tsx

Line 170 in 1466369

turnOnMobileSelectionMode();

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

• We can update:

App/src/components/Search/index.tsx

Line 169 in 1466369

if (selectedKeys.length > 0 && !selectionMode?.isEnabled) {

to:

        if (selectedKeys.length > 0 && !selectionMode?.isEnabled && !prevSelectionMode?.isEnabled) {

with prevSelectionMode = usePrevious(selectionMode)

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)