[HOLD for payment 2024-09-07][$250] Chat - Messages stuck highlighted when opening context menus consecutively

[lanitochka17]

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.0.7-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Action Performed:

1. Log in to New Expensify
2. Navigate to any chat with existing messages
3. Right click on a message
4. Right click on another message
5. Click anywhere to close context menu

Expected Result:

The second clicked message should not be highlighted

Actual Result:

The second clicked message remains highlighted

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

Bug6544401_1721161832467.2024-07-16_16-45-49.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010fad7b2cd94a8560
• Upwork Job ID: 1818656780802952530
• Last Price Increase: 2024-08-07

Issue Owner

Current Issue Owner: @anmurali

[melvin-bot]

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

[lanitochka17]

@anmurali FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[nyomanjyotisa]

Proposal

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

Messages stuck highlighted when opening context menus consecutively

What is the root cause of that problem?

App/src/pages/home/report/ContextMenu/ReportActionContextMenu.ts

Lines 128 to 133 in 9c509a0

	if (contextMenuRef.current.instanceID) {
	hideContextMenu();
	contextMenuRef.current.runAndResetOnPopoverHide();
	}
	contextMenuRef.current.showContextMenu(

if there is an already open context menu, we don't wait until the hideContextMenu done before executing showContextMenu

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

make showContextMenu and hideContextMenu functions async and add await to the hideContextMenu() call here

RESULT

New-Expensify.19.mp4

What alternative solutions did you explore? (Optional)

[melvin-bot]

@anmurali Eep! 4 days overdue now. Issues have feelings too...

[bernhardoj]

Proposal

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

Message background is stuck when open context menu while other context menu is showing.

What is the root cause of that problem?

When we open a context menu, we pass a show and hide callback to the popover.

App/src/pages/home/report/ReportActionItem.tsx

Lines 357 to 358 in 1084706

	() => setIsContextMenuActive(true),
	toggleContextMenuFromActiveReportAction,

Show callback will set the context menu active to true, while the hide callback will toggle the context menu and set it based on the context menu visibility.

When we open the first context menu and then open the second one, the hide callback of the first and second context menus is called. The hide callback is cleared when called.

Why the hide callback is called twice?

When we open a context menu, if an existing context menu is found, it will hide it first.

App/src/pages/home/report/ContextMenu/ReportActionContextMenu.ts

Lines 126 to 133 in 1084706

	// If there is an already open context menu, close it first before opening
	// a new one.
	if (contextMenuRef.current.instanceID) {
	hideContextMenu();
	contextMenuRef.current.runAndResetOnPopoverHide();
	}
	contextMenuRef.current.showContextMenu(

hideContextMenu() will set the context menu visibility to false while runAndResetOnPopoverHide() triggers the hide callback (1st hide callback).

Because we set the visibility to false, the context menu popover onModalHide is triggered, calling another runAndResetOnPopoverHide().

1. Open the first context menu, hide callback is set to the first context menu hide callback (callback = 1st)
2. Open the 2nd context menu.

• The first context menu hide callback is called (callback = empty) (hideContextMenu and runAndResetOnPopoverHide are called)
• The second context menu hide callback is set (callback = 2nd)
• The second context menu hide callback is called (callback = empty) (runAndResetOnPopoverHide is called by onModalHide)

3. Close the 2nd context menu, no hide callback is called, the highlight stays

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

If we look at the popover without overlay initial implementation, they face this problem before and that's why they added the code to close the current context menu before opening a new one in this commit.

App/src/pages/home/report/ContextMenu/ReportActionContextMenu.ts

Lines 126 to 133 in 1084706

	// If there is an already open context menu, close it first before opening
	// a new one.
	if (contextMenuRef.current.instanceID) {
	hideContextMenu();
	contextMenuRef.current.runAndResetOnPopoverHide();
	}
	contextMenuRef.current.showContextMenu(

But if you notice in the commit, we only call runAndResetOnPopoverHide to trigger the hide callback, which means we never set the context menu visibility to false (which also means the context menu never closes, just repositioned to a new position of the 2nd context menu).

But in this resolve conflict commit, they added hideContextMenu. I believe it's because to allow opening the 2nd context menu on the same message without any problem.

Why does the double hide callback happen now? I'm pretty sure it's because the component has gone through several changes. For example, if you move the setting visibility to true here

App/src/pages/home/report/ContextMenu/PopoverReportActionContextMenu.tsx

Line 216 in 1084706

setIsPopoverVisible(true);

to outside the promise, then the double hide callback won't happen since setIsPopoverVisible(false) and setIsPopoverVisible(true) are called almost right after the other, so the visibility state stays true. But in the current situation, the component has enough time to re-render the component with visibility of false, which triggers the extra runAndResetOnPopoverHide.

There solution is to wait until the current context menu is completely hidden before opening a new one. hideContextMenu second param supports a hide callback which we can use to show the second context menu after the 1st one is hidden.

if (contextMenuRef.current.instanceID) {
    hideContextMenu(undefined, // show context menu);
    // no need runAndResetOnPopoverHide
    return;
}
// show context menu immediately

Also, there is another bug where the popover instance ID is never cleared, so contextMenuRef.current.instanceID is always true. To fix that, we need to clear it in runAndResetOnPopoverHide.

App/src/pages/home/report/ContextMenu/PopoverReportActionContextMenu.tsx

Lines 241 to 245 in 5005f59

	const runAndResetOnPopoverHide = () => {
	reportIDRef.current = '-1';
	reportActionIDRef.current = '-1';
	originalReportIDRef.current = '-1';

setInstanceID('');

[melvin-bot]

@anmurali Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@anmurali 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[melvin-bot]

@anmurali this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@anmurali 12 days overdue. Walking. Toward. The. Light...