HOLD for payment 2024-04-03 [$500] Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar

[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: 1.4.46-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): kiatest.78+mass@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. Navigate to staging.new.expensify.com
2. Click Settings icon at bottom >> Workspaces
3. Tap on 3 dot menu for any WS
4. Select admin or announce room
5. Tap on header
6. Tap on WS avatar to view larger preview
7. Tap on 3 dot menu in WS chat (Note : 3 dot not working)
8. Go back to WS listing page
9. Tap on 3 dot menu for any WS

Expected Result:

3 dot menu in WS listing page (to access delete, admin & announce rooms) & in WS chat (to select unpin/pin option) should work after viewing WS avatar

Actual Result:

3 dot menu in WS listing/WS chat stops working after viewing WS avatar

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

Bug6398331_1709303779903.RPReplay_Final1709297090.mp4

Bug6398331_1709303779912.WEB.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d9482d637d6fa5bd
• Upwork Job ID: 1765134061012324352
• Last Price Increase: 2024-03-05
• Automatic offers:
• rayane-djouah | Contributor | 0

[melvin-bot]

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

[lanitochka17]

We think that this bug might be related to #wave6
CC @greg-schroeder

[lanitochka17]

@abekkala 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

[Krishna2323]

Proposal

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

Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar

What is the root cause of that problem?

isVisibleRef.current isn't properly synchronized with the component's unmounting process. This led to the cleanup function, responsible for hiding the modal during unmounting, potentially not being triggered when the modal was still visible. The hideModal is responsible for calling Modal.setModalVisibility(false);.

App/src/components/Modal/BaseModal.tsx

Lines 96 to 106 in af68510

	useEffect(
	() => () => {
	// Only trigger onClose and setModalVisibility if the modal is unmounting while visible.
	if (!isVisibleRef.current) {
	return;
	}
	hideModal(true);
	},
	// eslint-disable-next-line react-hooks/exhaustive-deps
	[],
	);

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

We should set isVisibleRef.current = isVisible; inside the useEffect which is responsible for hiding the modal during unmounting. By doing this we ensure that the isVisibleRef is in sync with isVisible. Or we can directly use isVisible and remove the isVisibleRef.

Remove the line below:

App/src/components/Modal/BaseModal.tsx

Line 80 in af68510

isVisibleRef.current = isVisible;

    useEffect(
        () => {
            isVisibleRef.current = isVisible;

            return () => {
                // Only trigger onClose and setModalVisibility if the modal is unmounting while visible.
                if (!isVisibleRef.current) {
                    return;
                }
                hideModal(true);
            };
        },
        // eslint-disable-next-line react-hooks/exhaustive-deps
        [],
    );

Both solutions works as expected

modal_onhide_issue.mp4

Alternatively

Remove isVisibleRef and directly use isVisible.

    useEffect(
        () => () => {
            // Only trigger onClose and setModalVisibility if the modal is unmounting while visible.
            if (!isVisible) {
                return;
            }
            hideModal(true);
        },
        // eslint-disable-next-line react-hooks/exhaustive-deps
        [],
    );

[bernhardoj]

Proposal

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

Can't open the three-dot menu after opening a workspace avatar.

What is the root cause of that problem?

The three-dot menu won't show when it's behind a modal.

App/src/components/ThreeDotsMenu/index.tsx

Line 86 in 22cb01c

const isBehindModal = modal?.willAlertModalBecomeVisible && !modal?.isPopover && !shouldOverlay;

The condition that always fails is modal?.willAlertModalBecomeVisible. When we open the WS avatar page, modal?.willAlertModalBecomeVisible will be true,

App/src/components/Modal/BaseModal.tsx

Lines 79 to 83 in 22cb01c

	useEffect(() => {
	isVisibleRef.current = isVisible;
	let removeOnCloseListener: () => void;
	if (isVisible) {
	Modal.willAlertModalBecomeVisible(true, type === CONST.MODAL.MODAL_TYPE.POPOVER || type === CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED);

but when we close the WS avatar page, modal?.willAlertModalBecomeVisible is never updated to false because hideModal is never called.

App/src/components/Modal/BaseModal.tsx

Lines 62 to 64 in 22cb01c

	const hideModal = useCallback(
	(callHideCallback = true) => {
	Modal.willAlertModalBecomeVisible(false);

hideModal will either be called when the avatar modal unmounts,

App/src/components/Modal/BaseModal.tsx

Lines 96 to 106 in 22cb01c

	useEffect(
	() => () => {
	// Only trigger onClose and setModalVisibility if the modal is unmounting while visible.
	if (!isVisibleRef.current) {
	return;
	}
	hideModal(true);
	},
	// eslint-disable-next-line react-hooks/exhaustive-deps
	[],
	);

but at the time the modal is unmounted, the visible state is already updated to false,

or when onModalHide is called.

App/src/components/Modal/BaseModal.tsx

Line 187 in 22cb01c

onModalHide={hideModal}

The first one already works as expected, but the second one is the issue. The reason it didn't get called is that when we press the close button of the WS avatar modal, it will update the visible state to false and call onModalClose,

App/src/components/AttachmentModal.tsx

Lines 388 to 396 in 22cb01c

	const closeModal = useCallback(() => {
	setIsModalOpen(false);
	if (typeof onModalClose === 'function') {
	onModalClose();
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [onModalClose]);

and in onModalClose, we close the WS avatar page.

App/src/pages/ReportAvatar.tsx

Lines 33 to 35 in 22cb01c

	onModalClose={() => {
	Navigation.goBack(ROUTES.REPORT_WITH_ID_DETAILS.getRoute(report?.reportID ?? ''));
	}}

So, the onModalHide didn't get a chance to be called because we closed the page too early.

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

We need to make sure the hideModal is called if the Modal is unmounted and hideModal is never called yet. To achieve that, we can create a new ref called shouldCallHideModalOnUnmount.

const shouldCallHideModalOnUnmount = useRef(false);
...
// unmount code
if (!shouldCallHideModalOnUnmount.current) {
    return;
}
hideModal(true);

We set it to true when the modal becomes visible.

App/src/components/Modal/BaseModal.tsx

Lines 83 to 87 in ddf9e7a

	if (isVisible) {
	Modal.willAlertModalBecomeVisible(true, type === CONST.MODAL.MODAL_TYPE.POPOVER || type === CONST.MODAL.MODAL_TYPE.BOTTOM_DOCKED);
	// To handle closing any modal already visible when this modal is mounted, i.e. PopoverReportActionContextMenu
	removeOnCloseListener = Modal.setCloseModal(onClose);
	}

And we set it to false when hideModal is called.

App/src/components/Modal/BaseModal.tsx

Lines 63 to 65 in ddf9e7a

	const hideModal = useCallback(
	(callHideCallback = true) => {
	Modal.willAlertModalBecomeVisible(false);

This will make sure the hideModal is called in a case where the Modal is previously visible and unmounted, but doesn't have the chance to call hideModal.

What alternative solutions did you explore? (Optional)

Or we can switch the order of setting the visible state and calling onModalClose.

App/src/components/AttachmentModal.tsx

Lines 388 to 394 in 22cb01c

	const closeModal = useCallback(() => {
	setIsModalOpen(false);
	if (typeof onModalClose === 'function') {
	onModalClose();
	}

[rayane-d]

Proposal

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

Can't open the three-dot menu after opening a workspace/profile/report avatar.

What is the root cause of that problem?

• In order for ThreeDotsMenu's PopoverMenu to show, isVisible prop here should become true => isBehindModal should be false here => willAlertModalBecomeVisible should be false.

• The root cause of the bug is that when we open the workspace/profile/report avatar modal, willAlertModalBecomeVisible will be true in Onyx, but when we close the avatar alert modal, willAlertModalBecomeVisible is not reset to false.

Explanation:

1. when we click on the close button, closeModal function is called in onCloseButtonPress of HeaderWithBackButton
2. when we execute closeModal function we set the isModalOpen state to false here and call the onModalClose function here
3. isModalOpen state is passed to isVisible prop of Modal here
   therefore, when we execute closeModal function, we set modal Visibility to false
4. we execute onModalClose in closeModal, in our case we will perform navigation. therefore BaseModal will unmount and we navigate before that onModalHide will be called here
5. hideModal function here is responsible for changing willAlertModalBecomeVisible to false here
6. hideModal will either be called when the base modal unmounts here or when we hide the modal by clicking outside
7. in our case hideModal is not called when the baseModal unmount because we return early here when isVisible is false.
8. when one of the workspace/profile/report avatar screens here is completely unmounted we set the modal visibility in Onyx to false here
   but willAlertModalBecomeVisible still true. this is why isBehindModal is true.

the bug also occurs when we click outside the modal (onBackButtonPress is triggered and call handleBackdropPress here which seéonClose => perform navigation =>)

we introduced isVisible for modal in Onyx in #1699 , and after that we added the listeners in #2050 , but when we added willAlertModalBecomeVisible for modal in Onyx in #5889 we didn't add Modal.willAlertModalBecomeVisible(false); call in here.

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

To fix this problem from root and prevent future similar bugs when using navigation inside onModalClose prop instead of onModalHide,
we should add Modal.willAlertModalBecomeVisible(false); call in here.

What alternative solutions did you explore? (Optional)

• here we can add :

        } else {
            Modal.willAlertModalBecomeVisible(false);
        }

to call it when we change visibility in here. this is happening before navigation => unmount.

• we can use onModalHide instead of onModalClose in the workspace/profile/report avatar modal, but this doesn't solve the issue completely and we can reintroduce the bug if we use navigation inside onModalClose in the future.

• switching the order of setting the visible state and calling onModalClose here, or setting isVisibleRef.current = isVisible; inside the useEffect which is responsible for hiding the modal during unmounting or directly using isVisible in it, may reintroduce the bug fixed here.

[melvin-bot]

@abekkala Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@abekkala Whoops! This issue is 2 days overdue. Let's get this updated quick!

[abekkala]

@lanitochka17 hmm, yeah, I feel that the 3 dot menu should always work