[Due for payment 2025-03-21] [$250] mWeb - Search type menu gets stuck when changing type

[m-natarajan]

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.1.6-0
Reproducible in staging?: yes
Reproducible in production?: yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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: @ikevin127
Slack conversation (hyperlinked to channel name): #expensify-bugs

Action Performed:

Open New Expensify app on mWeb.
2. Navigate to Reports.
3. Tap on the Search Type Menu button to open popover.
4. Switch search type to Chats.

Expected Result:

The search type menu popover should not freeze.

Actual Result:

The search type menu popover freezes when switching search type, blocking the user from interacting with the app.

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

ios-mweb.MP4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021896619851553050087
• Upwork Job ID: 1896619851553050087
• Last Price Increase: 2025-03-03
• Automatic offers:
• FitseTLT | Contributor | 106399888

Issue Owner

Current Issue Owner: @flaviadefaria

[melvin-bot]

Triggered auto assignment to @flaviadefaria (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.

[FitseTLT]

Proposal

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

mWeb - Search type menu gets stuck when changing type

What is the root cause of that problem?

Though we use shouldCallAfterModalHide this problem is caused by !isSafari check here

App/src/components/PopoverMenu.tsx

Line 215 in f965257

} else if (selectedItem.shouldCallAfterModalHide && !isSafari()) {

For shouldCallAfterModalHide cases we would normally close modals and call onSelected onModalDidClose

App/src/components/PopoverMenu.tsx

Lines 217 to 223 in f965257

	close(
	() => {
	selectedItem.onSelected?.();
	},
	undefined,
	selectedItem.shouldCloseAllModals,
	);

But now in safari the onSelected callback is called immediately after onItemSelected (which set isPopoverVisible false)

App/src/components/PopoverMenu.tsx

Lines 225 to 226 in f965257

	onItemSelected?.(selectedItem, index);
	selectedItem.onSelected?.();

and because the navigation in onSelected happens too quickly before the modal hides it will make the modal stuck and prevent the closing of the popover even if the state isVisible state is set to false.

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

We added the !isSafari check here to solve the attachment Native Menu not appearing for IOS web
So we have two options here

1. As I don't see the original problem now in safari we can remove the check
2. We can make the check optional and avoid applying it where it causes a problem like in this case via a param.(or only apply it where it is needed)

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

N / A

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[flaviadefaria]

Added the external label.

[linhvovan29546]

Duplicate of #57068