[HOLD] [$250] ReportActionContextMenu not closing properly

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open ND
2. Hover on any chat for report action context menu
3. Press Add reaction
4. Now press CTRL+K
5. Press the back arrow to close the search (RHP)
6. Now check the report action context menu after closing modal

   Expected Result:

   Report action context menu should be hidden, and be shown only on hovering

   Actual Result:

   Report action context menu gets stuck

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

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

• [ ] Android / native
• [ ] Android / Chrome
• [ ] iOS / native
• [ ] iOS / Safari
• [x] MacOS / Chrome / Safari
• [ ] MacOS / Desktop

Version Number: 1.3.48-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): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/43996225/be611be0-6900-438e-b88c-eb1b6b31347f

https://github.com/Expensify/App/assets/43996225/cdd035a1-892a-4edb-b17c-480c4b25215e

Expensify/Expensify Issue URL: Issue reported by: @shubham1206agra Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690723766793679

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013c8f7f084556466f
• Upwork Job ID: 1687252626772779008
• Last Price Increase: 2024-07-01
• Automatic offers:
• bernhardoj | Contributor | 26013711
• shubham1206agra | Reporter | 26013714

Issue Owner

Current Issue Owner: @ishpaul777

[melvin-bot[bot]]

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

[melvin-bot[bot]]

Bug0 Triage Checklist (Main S/O)

• [x] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• [x] This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• [x] This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• [x] This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• [x] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[vadymbokatov]

Proposal

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

ReportActionContextmenu not closing properly when mini emoji picker is opening.

What is the root cause of that problem?

When press openpicker button on mini report action context menu, it keeps context menu to open. https://github.com/Expensify/App/blob/3706f0becc425b818244f48b922e1337ffbbb5a2/src/pages/home/report/ContextMenu/ContextMenuActions.js#L66-L77

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

I think, to close context menu when press openpicker is the best option.

if (isMini) { 
     return ( 
         <MiniQuickEmojiReactions 
             key="MiniQuickEmojiReactions" 
             onEmojiSelected={toggleEmojiAndCloseMenu} 
             onEmojiPickerClosed={closeContextMenu} 
             reportActionID={reportAction.reportActionID} 
             reportAction={reportAction} 
         /> 
     ); 
 }

What alternative solutions did you explore? (Optional)

Result

https://github.com/Expensify/App/assets/138146362/2af15de2-af3d-4dcf-b087-74293a744f33

[jfquevedol2198]

Proposal

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

ReportActionContextMenu not closing properly

What is the root cause of that problem?

https://github.com/Expensify/App/blob/024d210bc0b5a0454b62a72de60057af67cdd045/src/components/EmojiPicker/EmojiPicker.js#L71-L77 In EmojiPicker, hideEmojiPicker action which is fired by onClose of Modal is not calling onModalHide.current if its being closed by navigating. Modal component's onModalHide performs parent element's close action, but when onClose is fired, it doesn't call onModalHide props of Modal component. so parent element (ReportActionContextMenu) is not closed and keeps showing although ReportAction is not hovered because shouldKeepOpen was not reseted by false.

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

If EmojiPicker is being closed by navigating, need to call onModalHide.current before initializing it.

    const hideEmojiPicker = (isNavigating) => {
        if (isNavigating) {
            if (onModalHide.current) onModalHide.current();
            onModalHide.current = () => {};
        }
        emojiPopoverAnchor.current = null;
        setIsEmojiPickerVisible(false);
    };

Result

https://github.com/Expensify/App/assets/137529618/c3fa3cdb-ce8f-4aba-a415-101f5c9ae0b7

What alternative solutions did you explore? (Optional)

N/A

[bernhardoj]

Proposal

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

The mini context menu does not hide if an emoji picker is open while navigating to another page with a shortcut.

What is the root cause of that problem?

The mini context menu will show when the report action is hovered or shouldKeepOpen state is true. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L87-L88

As soon as we open the emoji picker, the report action will lose its hovered state, and instead, the shouldKeepOpen state becomes true. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/ContextMenuActions.js#L71 https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L101

shouldKeepOpen will become false when we close the emoji picker. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/ContextMenuActions.js#L72 https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/ContextMenuActions.js#L47-L52 https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ContextMenu/BaseReportActionContextMenu.js#L100

The emoji picker relies on the modal onModalHide callback to notify that the emoji picker is closed. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/components/EmojiPicker/EmojiPicker.js#L149 https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/components/EmojiPicker/EmojiPicker.js#L47-L48

However, when we use a shortcut to go to other pages, we will close any modal that is visible, wait for it to close, and do the navigation. On closing the picker, we check if isNavigating is true, and if true, we clear the onModalHide callback. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/components/EmojiPicker/EmojiPicker.js#L71-L74

isNavigating is true when we are navigating to other pages. This is useful to prevent the composer picker modal hide callback that will refocus the composer. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ReportActionCompose.js#L1199-L1203

Because the hide callback is cleared, we have no way to notify the mini context menu to set the shouldKeepOpen back to false.

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

We shouldn't clear the modal hide callback because there are cases where we need to have the hide callback. Instead, we can pass the isNavigating value to the onModalHide callback and let each component that uses it decide what to do based on isNavigating value.

For example, on ReportActionCompose (and ReportActionItemMessageEdit), we will only focus back the composer if isNavigating is false. https://github.com/Expensify/App/blob/52b8ddc2a5edc1b2d2ddbde20b95779dbbdb6380/src/pages/home/report/ReportActionCompose.js#L1201-L1203

onModalHide={(isNavigating) => {
    if (!isNavigating) this.focus(true);
}}

What alternative solutions did you explore? (Optional)

Alternative 1: Pass a new parameter to showEmojiPicker called forceHideCallback. If forceHideCallback is true, we won't clear the hide callback.

Alternative 2: This alternative requires the most changes, but I think the best. As explained in my root cause, isNavigating is useful to prevent the composer picker modal hide callback that will refocus the composer after navigating. The real reason isNavigating is added is that we put a delay before focusing the composer after the emoji picker is closed. https://github.com/Expensify/App/blob/c3bafa67302f5de421c260f3688b5fca656cdc06/src/pages/home/report/ReportActionCompose.js#L750-L764

This means, without isNavigating, we will navigate to the search page and after some delay, we will focus the main composer.

The focus delay is added as a workaround for the modal issue where onModalHide is called too early (this is a well-known issue). If we remove this workaround, we don't need to have the isNavigating logic anymore. So, here is the plan:

1. Fix the onModalHide callback is called too early. This fix requires an upstream (react-native-modal) fix. a. We should call onModalHide in Modal onDismiss callback. Will open PR after both below are fixed. b. onDismiss callback is not available in Android, but I have an open PR for it. c. onDismiss is called too early on rn-web, but I have an open PR for it.
2. Remove the focus delay (InteractionManager + setTimeout) workaround from composer
3. Remove all usage of isNavigating workaround.

[adelekennedy]

Trying to reproduce on chrome staging (v1.3.49-1) or prod (v1.3.48-5) and I'm not getting the same result - the ra context menu doesn't reappear. I think this may have been fixed. checking in Slack

[jfquevedol2198]

@adelekennedy I can see this on New Dot and Staging.

[adelekennedy]

moving this forward!

[melvin-bot[bot]]

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

[melvin-bot[bot]]

Current assignee @adelekennedy is eligible for the External assigner, not assigning anyone new.

[melvin-bot[bot]]

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

[studentofcoding]

Proposal

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

ReportActionContextMenu not closing properly

What is the root cause of that problem?

This hideEmojiPicker function not covering the case when what to do when being overlapped by Navigating, therefore this condition should be added.

https://github.com/Expensify/App/blob/024d210bc0b5a0454b62a72de60057af67cdd045/src/components/EmojiPicker/EmojiPicker.js#L66-L77

Lines 71 to 77 in 024d210

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

Need to check the status of onModulaHide.current and init that.

const hideEmojiPicker = (isNavigating) => {
        if (isNavigating) {
            if (onModalHide.current) onModalHide.current(); // This is the condition to handle the case
            onModalHide.current = () => {};
        }
        emojiPopoverAnchor.current = null;
        setIsEmojiPickerVisible(false);
    };

What alternative solutions did you explore? (Optional)

N/A

Result

https://www.loom.com/share/6f506f43b8e04c57ae5da5a979c1df2e?sid=034af9be-bf27-490c-81f6-4a19184fa3c1

[nileshahir286]

Contributor details Your Expensify account email: nileshahir286@gmail.com Upwork Profile Link: https://www.upwork.com/freelancers/~0126f3665fe23ff297

Proposal

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

Report Context Menu should be closed, now it's stuck after close the modal.

What is the root cause of that problem?

Report Context Menu should only be show when hover on icon.

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

When you press CTRL+K, at that time the context menu should hide.

[melvin-bot[bot]]

⚠️ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.

[nileshahir286]

⚠️ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.

Already include Upwork profile as well as Expensify email id.

[bernhardoj]

Updated my proposal to include more alternative solutions.

[adelekennedy]

pending review on the updated proposal

[robertKozik]

I'll review it as the first thing tomorrow 👌🏼

[robertKozik]

Hi, thank you all for your proposals. I'll try to address them all:

1) @studentofcoding / @jfquevedol2198 - both of your proposals suggest triggering the onModalHide function before clearing it. I think it could cause lots of regression problems. Basically, this trigger renders the entire if statement irrelevant in my eyes. https://github.com/Expensify/App/blob/012d604753e6ed2f97736d47b28486f813995165/src/components/EmojiPicker/EmojiPicker.js#L72-L74 2) @nileshahir286 - I think your proposal is too general to be taken under consideration. 3) @bernhardoj - I think your proposal is well-suited to be chosen. I really like the idea of passing the isNavigating state to decide on the behavior of onHide using the callback function. I believe it's the most flexible solution and can be future-proof. I agree with you that your second alternative solution would be the go-to, as it could allow us to eliminate the need for delaying focus. However, it appears that we might have to wait a considerable time until your PRs are merged upstream, and then the versions of these libraries would have to be updated within this repository as well. In my opinion, we should address this bug more promptly, but let's see what CME will think about it.

With that said, I believe we should choose the @bernhardoj proposal and push it forward.

Selected Proposal: Proposal Author of proposal: @bernhardoj

[robertKozik]

forgot the secret formula 🥲

🎀 👀 🎀 C+ reviewed

[melvin-bot[bot]]

Triggered auto assignment to @puneetlath, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[puneetlath]

I like the idea of going with the ideal solution that includes the upstream fixes. This doesn't seem like such an urgent bug to me, so I'd rather take our time and go with the ideal approach.

[melvin-bot[bot]]

📣 @bernhardoj 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[melvin-bot[bot]]

📣 @shubham1206agra 🎉 An offer has been automatically sent to your Upwork account for the Reporter role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job

[puneetlath]

@robertKozik is there anyone from SWM that might be able to help us get some traction on the upstream PRs?

[bernhardoj]

help us get some traction on the upstream PRs

yes, this would be great, it's been inactive for weeks 😢

[robertKozik]

@puneetlath shared on internal slack channel edit: @tomekzaw is on it 🚀

[WoLewicki]

Hey, I tested the changes and commented on the PR for react-native: https://github.com/facebook/react-native/pull/38336#discussion_r1291452892, hopefully we can move it forward 🚀

[bernhardoj]

Still waiting for an update on both rn and rn-web PR.

[melvin-bot[bot]]

@puneetlath @bernhardoj @adelekennedy @robertKozik this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[melvin-bot[bot]]

@puneetlath @bernhardoj @adelekennedy @robertKozik this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[robertKozik]

@puneetlath Can we put this issue on hold as we are waiting for upstream PRs?

[puneetlath]

Yes, absolutely. Which exact PRs are we putting this on hold for. Let's make sure we have a list so we know when to take this off hold.

[bernhardoj]

RN PR: https://github.com/facebook/react-native/pull/38336 (waiting for RN team confirmation) RN-web PR: https://github.com/necolas/react-native-web/pull/2558 (bumped the PR for review)

[puneetlath]

Thanks @bernhardoj. @adelekennedy can we please put this on hold for those?

[bernhardoj]

Status update: RN PR: still working on it, trying to find a better solution RN-web PR: merged, released in 0.19.8

[robertKozik]

PR in react-native still open - not overdue

[bernhardoj]

Bumped the react-native PR for review, still no update.

[adelekennedy]

no update

[bernhardoj]

Still no review from the maintainer. Bumped the PR for review.

[puneetlath]

Still on hold for upstream.

[adelekennedy]

I think we're still on hold here

[adelekennedy]

Still holding here!

[bernhardoj]

Just bumped the PR again 2 days ago, still no review.

[adelekennedy]

woof - we're just holding on this still until they update the PR, should we downgrade this to monthly?

[bernhardoj]

Just bumped the PR again (it's been 3 months without an update 😭). I think we can make this monthly.

cc: @adelekennedy

[shubham1206agra]

@adelekennedy Should we go towards a workaround solution which @bernhardoj previously proposed?

[puneetlath]

Can you remind me what the workaround is? We should evaluate whether the bug is bad enough to justify a workaround.

[robertKozik]

I think we are talking about the Alternative 1 from there.

[bernhardoj]

Oh, I miss this one. It's either the alternative 1 or the main solution that @robertKozik previously approved.

Or do we want to create a patch? (never created one though)