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

lanitochka17 · 2024-03-01T15:42:28Z

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: 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): [email protected]
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

Navigate to staging.new.expensify.com
Click Settings icon at bottom >> Workspaces
Tap on 3 dot menu for any WS
Select admin or announce room
Tap on header
Tap on WS avatar to view larger preview
Tap on 3 dot menu in WS chat (Note : 3 dot not working)
Go back to WS listing page
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?

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 · 2024-03-01T15:42:41Z

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

lanitochka17 · 2024-03-01T15:44:04Z

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

lanitochka17 · 2024-03-01T15:44:25Z

@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 · 2024-03-02T05:40:00Z

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 · 2024-03-02T11:25:34Z

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 · 2024-03-03T16:51:52Z

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:

when we click on the close button, closeModal function is called in onCloseButtonPress of HeaderWithBackButton
when we execute closeModal function we set the isModalOpen state to false here and call the onModalClose function here
isModalOpen state is passed to isVisible prop of Modal here
therefore, when we execute closeModal function, we set modal Visibility to false
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
hideModal function here is responsible for changing willAlertModalBecomeVisible to false here
hideModal will either be called when the base modal unmounts here or when we hide the modal by clicking outside
in our case hideModal is not called when the baseModal unmount because we return early here when isVisible is false.
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 · 2024-03-04T15:48:01Z

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

melvin-bot · 2024-03-05T15:21:18Z

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

abekkala · 2024-03-05T21:55:23Z

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

melvin-bot · 2024-03-05T21:55:31Z

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

melvin-bot · 2024-03-05T21:55:36Z

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

kmbcook · 2024-03-06T19:48:34Z

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?

BaseModal sets willAlertModalBecomeVisible to true, but fails to set it back to false after the modal is closed. After the modal closes there is no reason for willAlertModalBecomeVisible to be true, since the modal will not become visible because it has closed.

App/src/components/Modal/BaseModal.tsx

Lines 79 to 94 in 44fc9e1

    
           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); 
        
                   // To handle closing any modal already visible when this modal is mounted, i.e. PopoverReportActionContextMenu 
        
                   removeOnCloseListener = Modal.setCloseModal(onClose); 
        
               } 
        
               return () => { 
        
                   if (!removeOnCloseListener) { 
        
                       return; 
        
                   } 
        
                   removeOnCloseListener(); 
        
               }; 
        
           }, [isVisible, wasVisible, onClose, type]);

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

Set willAlertModalBecomeVisible to false when BaseModal closes. Do this by calling Modal.willAlertModalBecomeVisible(false) in the clean-up function which is called when the modal closes, this function.

App/src/components/Modal/BaseModal.tsx

Lines 88 to 93 in 44fc9e1

    
           return () => { 
        
               if (!removeOnCloseListener) { 
        
                   return; 
        
               } 
        
               removeOnCloseListener(); 
        
           };

abekkala · 2024-03-06T21:36:10Z

@allroundexperts when you have a moment can you review the proposals that have come in so far?

sarahRosannaBusch · 2024-03-06T23:24:06Z

Proposal

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

The Three Dots Menu stops working after viewing WS Avatar in a preview modal.

What is the root cause of that problem?

After viewing the avatar in the modal then clicking the ThreeDotsMenu, its hidePopoverMenu() is called immediately after showPopoverMenu() so the popover is never visible. This is happening because the modal used to view the avatar is not tracking it's state properly, and the Three Dot Menu is being automatically closed when it thinks the modal is open.

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

The Three Dots Menu should not be dependent on the state of the modal.

In src/components/ThreeDotsMenu/index.tsx the isBehindModal variable and useEffect() function should be removed entirely as they are not needed. Without them, the onPress event is the only thing determining when to show/hide the popover menu, so it is always correct. (I've tested on all platforms to confirm this is true.)

What alternative solutions did you explore? (Optional)

The modal state bug, as others have already proposed, should also be fixed - but maybe as a separate issue?

allroundexperts · 2024-03-07T16:59:21Z

In src/components/ThreeDotsMenu/index.tsx the isBehindModal variable and useEffect() function should be removed entirely as they are not needed. Without them, the onPress event is the only thing determining when to show/hide the popover menu, so it is always correct. (I've tested on all platforms to confirm this is true.)

We occasionally open the modals by keyboard shortcuts as well. This would fail in that case.

sarahRosannaBusch · 2024-03-07T17:38:34Z

We occasionally open the modals by keyboard shortcuts as well. This would fail in that case.

My solution still works for this case, because the popover menu is closed on blur (not by a close button). So anytime the user does anything it is already closing properly. I've tried this using the shortcuts to open the RHP and LHP, but I'm not actually seeing a shortcut to open a modal. Am I missing something?

allroundexperts · 2024-03-07T21:14:34Z

My solution still works for this case, because the popover menu is closed on blur (not by a close button). So anytime the user does anything it is already closing properly. I've tried this using the shortcuts to open the RHP and LHP, but I'm not actually seeing a shortcut to open a modal. Am I missing something?

No, I just tested it and it seems to work. However, can you verify if applying your fix won't bring back #33541?

allroundexperts · 2024-03-07T21:22:53Z

Thanks for your proposal @kmbcook. I see that your solution is similar to what @rayane-djouah proposed earlier. You're suggesting to apply the same fix at a different place. Is there any reason for it? How is it any better from applying it at the screen level?

allroundexperts · 2024-03-07T21:41:51Z

I'm leaning towards @rayane-djouah's proposal since it fixes the problem at its root. The other proposals seem to be more of a patch work on the original problem. That being said, I'm open to a discussion if anyone disagrees.

🎀 👀 🎀 C+ reviewed

bernhardoj · 2024-03-12T13:05:34Z

@allroundexperts bump

kmbcook · 2024-03-12T21:27:30Z

Thanks for your proposal @kmbcook. I see that your solution is similar to what @rayane-djouah proposed earlier. You're suggesting to apply the same fix at a different place. Is there any reason for it? How is it any better from applying it at the screen level?

I actually didn't read that earlier proposal carefully. Looks like it is better.

allroundexperts · 2024-03-18T00:35:05Z

@bernhardoj I went through your proposal again and I still think that @rayane-djouah's proposal is better. In my opinion, we should not rely on hideModal to be called in order to fully close the modal. If someone dismisses the modal by navigation, willAlertModalBecomeVisible should become false automatically. With your approach, we would have to call onModalHide explicitly in other pages as well just like you mentioned in your proposal. Even if we fix those pages now, I am pretty sure that this issue would return as new modals are added. A better way to do this in my opinion would be to detach this dependency on onModalHide call.

I hope that clarified the reasoning for selecting @rayane-djouah's proposal.

bernhardoj · 2024-03-18T06:55:59Z

@allroundexperts I'm still unconvinced about setting the willAlertModalBecomeVisible when a page is removed from navigation. Even if we do it, we will still need to replace onModalClose with onModalHide to fix this issue #37634 as they have the same root cause.

I think it's just about the attachment modal lifecycle. The onModalClose is called when the user request to close the modal. If we immediately do a navigation, then onModalHide will never be called. Calling Modal.willAlertModalBecomeVisible when a page is removed doesn't solve the root cause of the issue.

Even if we fix those pages now, I am pretty sure that this issue would return as new modals are added.

We can just remove the onModalClose if that's confusing as it's only being used in report, WS, profile avatar, and transaction receipt page to navigate away.

Or if we still want to keep the onModalClose, then we need to change the ref here to isHideModalCalled.current and call hideModal when it's not yet called in case the animation is still ongoing.

App/src/components/Modal/BaseModal.tsx

Lines 96 to 103 in c915e7f

    
           useEffect( 
        
               () => () => { 
        
                   // Only trigger onClose and setModalVisibility if the modal is unmounting while visible. 
        
                   if (!isVisibleRef.current) { 
        
                       return; 
        
                   } 
        
                   hideModal(true); 
        
               },

Krishna2323 · 2024-03-18T10:49:25Z

I agree with @bernhardoj, we aren't solving the root cause here. hideModal(true) should be called when page unmounts and it will handle everything.

App/src/components/Modal/BaseModal.tsx

Lines 96 to 103 in c915e7f

    
           useEffect( 
        
               () => () => { 
        
                   // Only trigger onClose and setModalVisibility if the modal is unmounting while visible. 
        
                   if (!isVisibleRef.current) { 
        
                       return; 
        
                   } 
        
                   hideModal(true); 
        
               },

App/src/components/Modal/BaseModal.tsx

Lines 62 to 77 in c915e7f

    
           const hideModal = useCallback( 
        
               (callHideCallback = true) => { 
        
                   Modal.willAlertModalBecomeVisible(false); 
        
                   if (shouldSetModalVisibility) { 
        
                       Modal.setModalVisibility(false); 
        
                   } 
        
                   if (callHideCallback) { 
        
                       onModalHide(); 
        
                   } 
        
                   Modal.onModalDidClose(); 
        
                   if (!fullscreen) { 
        
                       ComposerFocusManager.setReadyToFocus(); 
        
                   } 
        
               }, 
        
               [shouldSetModalVisibility, onModalHide, fullscreen], 
        
           );

allroundexperts · 2024-03-18T10:52:35Z

We can just remove the onModalClose if that's confusing as it's only being used in report, WS, profile avatar, and transaction receipt page to navigate away.

@bernhardoj Are you sure that removing this will not cause any regressions?

bernhardoj · 2024-03-18T11:51:57Z

@allroundexperts after some testing, I found that replacing onModalClose with onModalHide caused a regression.

Open profile avatar
Press the browser/device back button
There will be 2 navigation back happen, one from the browser/native, one from onModalHide

Now I know why we use onModalClose because it will never be called when we navigate using the browser/device back button.

So, we can't use the solution of replacing onModalClose with onModalHide, but we still need a solution that makes sure hideModal is called instead of only Modal.willAlertModalBecomeVisible.

allroundexperts · 2024-03-19T22:04:51Z

So, we can't use the solution of replacing onModalClose with onModalHide, but we still need a solution that makes sure hideModal is called instead of only Modal.willAlertModalBecomeVisible.

For now, I still feel like the chosen proposal is the best one.

Krishna2323 · 2024-03-19T22:07:10Z

@allroundexperts, what do you think about my proposal? It works as expected.

bernhardoj · 2024-03-20T02:29:47Z

@allroundexperts I have updated my proposal's main solution to make sure hideModal is called. If it still doesn't convince you, can you ask to reopen #37634 and I can move my proposal there?

melvin-bot · 2024-03-22T18:59:07Z

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

abekkala · 2024-03-22T19:00:10Z

@isabelastisser I'm ooo until April 08 - I'll be taking back any issues still Open once I return

CURRENT STATUS:

@allroundexperts has chosen a proposal by @rayane-djouah. A PR has already been merged: #38098 which was just deployed to staging. Once it has deployed to prod this issue should update with a payment date.

Fix: @rayane-djouah [$500, pending no regressions]
PR: Review @allroundexperts [$500, pending no regressions]

isabelastisser · 2024-03-28T19:28:01Z

No updates.

rayane-d · 2024-03-30T23:32:12Z

@isabelastisser PR was deployed to production #38098 (comment) on Mar, 27.
This should be [HOLD for payment 2024-04-03]

isabelastisser · 2024-04-04T00:53:20Z

Payment summary:

Fix: @rayane-djouah $500 - paid in Upwork
PR: Review @allroundexperts $500 - pending payment in newdot.

isabelastisser · 2024-04-05T02:41:39Z

Payment summary:

PENDING:

PR: Review @allroundexperts $500 - pending payment in newdot.

JmillsExpensify · 2024-05-03T17:27:41Z

$500 approved for @allroundexperts

lanitochka17 added Daily KSv2 Bug Something is broken. Auto assigns a BugZero manager. labels Mar 1, 2024

melvin-bot bot assigned abekkala Mar 1, 2024

melvin-bot bot added the Overdue label Mar 3, 2024

melvin-bot bot removed the Overdue label Mar 5, 2024

abekkala added External Added to denote the issue can be worked on by a contributor Overdue labels Mar 5, 2024

melvin-bot bot changed the title ~~Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar~~ [$500] Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar Mar 5, 2024

melvin-bot bot added the Help Wanted Apply this label when an issue is open to proposals by contributors label Mar 5, 2024

melvin-bot bot assigned allroundexperts Mar 5, 2024

melvin-bot bot removed the Overdue label Mar 5, 2024

melvin-bot bot added Weekly KSv2 and removed Weekly KSv2 labels Mar 13, 2024

rayane-d mentioned this issue Mar 15, 2024

[$250] Distance - 3-dot menu does not open after returning from receipt view #38231

Closed

6 tasks

abekkala removed their assignment Mar 22, 2024

abekkala added Bug Something is broken. Auto assigns a BugZero manager. and removed Bug Something is broken. Auto assigns a BugZero manager. labels Mar 22, 2024

melvin-bot bot assigned isabelastisser Mar 22, 2024

melvin-bot bot added Daily KSv2 and removed Weekly KSv2 labels Mar 22, 2024

abekkala self-assigned this Mar 22, 2024

bernhardoj mentioned this issue Apr 2, 2024

[HOLD for payment 2024-06-06] [$500] Web - CTRL + K does not open Search while user avatar preview opened #37634

Closed

6 tasks

isabelastisser changed the title ~~[$500] Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar~~ HOLD for payment 2024-04-03 [$500] Workspace - 3 dot menu in WS listing/WS chat stops working after viewing WS avatar Apr 2, 2024

isabelastisser closed this as completed Apr 5, 2024

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

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

Comments

lanitochka17 commented Mar 1, 2024 • edited by melvin-bot bot Loading

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

melvin-bot bot commented Mar 1, 2024

lanitochka17 commented Mar 1, 2024

lanitochka17 commented Mar 1, 2024

Krishna2323 commented Mar 2, 2024 • edited Loading

Proposal

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

What is the root cause of that problem?

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

Both solutions works as expected

Alternatively

bernhardoj commented Mar 2, 2024 • edited Loading

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

rayane-d commented Mar 3, 2024

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

melvin-bot bot commented Mar 4, 2024

melvin-bot bot commented Mar 5, 2024

abekkala commented Mar 5, 2024

melvin-bot bot commented Mar 5, 2024

melvin-bot bot commented Mar 5, 2024

kmbcook commented Mar 6, 2024 • edited Loading

Proposal

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

What is the root cause of that problem?

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

abekkala commented Mar 6, 2024

sarahRosannaBusch commented Mar 6, 2024

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

allroundexperts commented Mar 7, 2024

sarahRosannaBusch commented Mar 7, 2024

allroundexperts commented Mar 7, 2024

allroundexperts commented Mar 7, 2024

allroundexperts commented Mar 7, 2024

bernhardoj commented Mar 12, 2024

kmbcook commented Mar 12, 2024

allroundexperts commented Mar 18, 2024

bernhardoj commented Mar 18, 2024

Krishna2323 commented Mar 18, 2024

allroundexperts commented Mar 18, 2024

bernhardoj commented Mar 18, 2024

allroundexperts commented Mar 19, 2024

Krishna2323 commented Mar 19, 2024

bernhardoj commented Mar 20, 2024

melvin-bot bot commented Mar 22, 2024

abekkala commented Mar 22, 2024

CURRENT STATUS:

isabelastisser commented Mar 28, 2024

rayane-d commented Mar 30, 2024

isabelastisser commented Apr 4, 2024

isabelastisser commented Apr 5, 2024

JmillsExpensify commented May 3, 2024

lanitochka17 commented Mar 1, 2024 •

edited by melvin-bot bot

Loading

Krishna2323 commented Mar 2, 2024 •

edited

Loading

bernhardoj commented Mar 2, 2024 •

edited

Loading

kmbcook commented Mar 6, 2024 •

edited

Loading