[HOLD for payment 2023-05-25] [$1000] On click of ESC while 'copy URL to clipboard' popup is open, app closes both 'copy URL to clipboard' popup and RHN

[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 the app
2. Open settings
3. Right click on Help to open 'copy URL to clipboard'
4. Click on ESC

Expected Result:

App should only close 'copy URL to clipboard' popup on ESC click like it does for delete workspace popup

Actual Result:

App closes both 'copy URL to clipboard' popup and RHN on single ESC click

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
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.11.2
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

Recording.520.mp4

on.esc.app.closes.both.RHN.and.copy.popup.mp4

Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1683388261937479

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01f4c841961ae2e365
• Upwork Job ID: 1656822582847545344
• Last Price Increase: 2023-05-12

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• 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
• 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.
• 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.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[huzaifa-99]

Proposal

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

We are trying to handle the escape key in a priority order. So the last modal opened should be the first one closed.

What is the root cause of that problem?

The problem is related to the whole right side modal, any open context menu will be closed along with the right side modal itself on escape press.

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

When escape is pressed, we should check if the context menu is open and if it is we should prevent the modal from closing. There are 2 approaches to this

Approach 1: Global changes (Suggested)

We can update the PopoverReportActionContextMenu and add a new method

isVisible() {
    return this.state.isPopoverVisible
}

and also add it to ReportActionContextMenu

function isVisible() {
    return contextMenuRef.current.isVisible();
}

Now in the ScreenWrapper we can check if the context menu is visible and prevent escape on the modal if it is here

App/src/components/ScreenWrapper/index.js

Line 44 in 2c3eec0

if (this.props.modal.willAlertModalBecomeVisible) {

by updating it with this

if (this.props.modal.willAlertModalBecomeVisible || ReportActionContextMenu.isVisible()) {

This will correctly handle the escape listener.

Additionally instead of just passing the visible state we can pass the current state from the ReportActionContextMenu

function getCurrentState() {
    return contextMenuRef.current.getCurrentState();
}

so we can use this for much more conditional checks.

Important: The above changes will focus the Help menu item with a blue border when escape is pressed, if we want to prevent that we also blur the menu item on escape (DomUtils.blurActiveElement()).

Approach 2: Local changes

We do local updates to the InitialSettingsPage to check if the context menu is open, so replacing this line

App/src/pages/settings/InitialSettingsPage.js

Line 252 in 2c3eec0

onSecondaryInteraction={!_.isEmpty(item.link) ? e => ReportActionContextMenu.showContextMenu(CONTEXT_MENU_TYPES.LINK, e, item.link, this.popoverAnchor.current) : undefined}

with

onSecondaryInteraction={!_.isEmpty(item.link) ? e => {
    return ReportActionContextMenu.showContextMenu(
        CONTEXT_MENU_TYPES.LINK,
        e,
        item.link,
        this.popoverAnchor.current,
        '0',
        {},
        '',
        () => { /* context menu got opened: store bool in state */ },
        () => { /* context menu got closed: update bool in state */},
    )
} : undefined}

and store state value for when context menu is opened/closed.

Next we add a new prop preventDismissOnEscKey on the ScreenWrapper and in the escape key press listener here

App/src/components/ScreenWrapper/index.js

Line 44 in 2c3eec0

if (this.props.modal.willAlertModalBecomeVisible) {

we update the condition to check if we should prevent escape key from closing the modal

if (this.props.modal.willAlertModalBecomeVisible || this.props.preventDismissOnEscKey) {
   return
   // ...

Finally we have to pass the prop from the InitialSettingsPage

<ScreenWrapper 
    includeSafeAreaPaddingBottom={false} 
    preventDismissOnEscKey={ /* here we pass the state value stored earlier */ }
>

What alternative solutions did you explore? (Optional)

N/A

[mallenexpensify]

@dhanashree-sawant and/or @huzaifa-99 , can you please document all areas of the app where this is happening so we can fix them at one time? I see two more instances here

[dhanashree-sawant]

HI @mallenexpensify, Sure will go through it and let you know all the instances.

[huzaifa-99]

@mallenexpensify, @dhanashree-sawant I was able to find these

1. In /settings/about/app-download-links (all 3 of these links have a popover)

2. In /settings/about, 'View the code' and 'View open jobs' have a popover

3. In get-assistance/:taskId ex: get-assistance/16247, 'Explore help docs' has a popover

4. Also the 'help' link on the settings page has a popover (the original bug report)

---

All of these can be fixed by the Approach 1 suggested in this proposal.

[dhanashree-sawant]

Few more instances of the issue which @huzaifa-99 missed:

1. In settings page, help link
   
2. In settings->workspaces->any workspace->Reimburse expenses->View all receipts link
   
3. In settings->workspaces->any workspace->Pay bills->View all bills link
   
4. In settings->workspaces->any workspace->Send invoices-> send invoice link and view all invoices link
   

[huzaifa-99]

Thanks for spotting @dhanashree-sawant.

@mallenexpensify I did a quick test against the newly spotted areas, and Approach 1 in this proposal also works there.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[mallenexpensify]

Thanks @huzaifa-99 and @dhanashree-sawant , teamwork!!!
@s77rt , can you please review?

[allroundexperts]

My proposal here solves this issue by actually fixing the root cause.

[s77rt]

@huzaifa-99 Thanks for the proposal. I don't think your RCA is complete. It seems that you are treating this bug as a feature request but it's actually a bug, the feature is already implemented on ScreenWrapper.

[s77rt]

@allroundexperts Thanks for the proposal. Your RCA is correct; We are missing the case where the modal is initially rendered visible. The suggested fix makes sense; Cover that case by calling willAlertModalBecomeVisible on componentDidMount.

I just have a non-blocking question, what cases would it cover calling willAlertModalBecomeVisible on componentWillUnmount.

🎀 👀 🎀 C+ reviewed
cc @techievivek

And please copy the proposal from the other issue to this for visibility.

[allroundexperts]

Thanks for your review @s77rt. componentWillUnmount will cover all the cases where we're controlling the modal visibility by mounting / un-mounting the component.

[s77rt]

@allroundexperts Yeah I got the idea. I'm asking if you can pinpoint a real existing case. I'm asking because although we mostly have 1 visible modal at a time, we may have n rendered modal at a time. If we are going to call willAlertModalBecomeVisible on componentWillUnmount we need to make sure that the modal getting unmounted was actually visible.

[allroundexperts]

@allroundexperts Yeah I got the idea. I'm asking if you can pinpoint a real existing case. I'm asking because although we mostly have 1 visible modal at a time, we may have n rendered modal at a time. If we are going to call willAlertModalBecomeVisible on componentWillUnmount we need to make sure that the modal getting unmounted was actually visible.

@s77rt I'm not sure if I am following your question exactly but I'll take a shot. Even the context menu (as in this bug) is a real case. Without the function in unmount, when you'll press escape, the modal will close. But pressing it again won't close the RHN, since the willAlertModalBecomeVisible will be true even after unmount.

[melvin-bot]

📣 @allroundexperts You have been assigned to this job by @techievivek!
Please apply to this job in Upwork 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 📖

[techievivek]

Not overdue. Job has been assigned to @allroundexperts

[allroundexperts]

PR created #18982

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.15-12 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• fix: fix escape shortcut for closing of popovers #18982

If no regressions arise, payment will be issued on 2023-05-25. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@s77rt] The PR that introduced the bug has been identified. Link to the PR:
• [@s77rt] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@s77rt] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@s77rt] Determine if we should create a regression test for this bug.
• [@s77rt] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@mallenexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: https://github.com/Expensify/Expensify/issues/287386

[s77rt]

• The PR that introduced the bug has been identified: This existed since day one. The following PR could have fixed it but it's not a regression Fix: Modal and screen closing with single esacpe keypress #5889
• The offending PR has been commented on: Fix: Modal and screen closing with single esacpe keypress #5889 (comment)
• A discussion in #expensify-bugs has been started: https://expensify.slack.com/archives/C049HHMV9SM/p1684430857010149
• Determine if we should create a regression test for this bug: Yes

---

Regression Test Proposal

1. Open App
2. Go to Settings
3. Right click on "Help"
4. Verify a modal popover is shown
5. Press ESC
6. Verify the modal is closed but the Settings page is still shown
7. Press ESC
8. Verify the Settings page is closed

[mallenexpensify]

@s77rt , @allroundexperts , @dhanashree-sawant can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~01f4c841961ae2e365

[s77rt]

@mallenexpensify Accepted!

[dhanashree-sawant]

Thanks @mallenexpensify, Accepted the offer.

[allroundexperts]

@s77rt , @allroundexperts , @dhanashree-sawant can you please accept the job and reply here once you have? https://www.upwork.com/jobs/~01f4c841961ae2e365

@mallenexpensify Accepted.

[techievivek]

Not overdue, we are waiting for the payment to complete.

[mallenexpensify]

@dhanashree-sawant paid $250 for reporting, @s77rt and @allroundexperts paid $1500, including the 50% timeliness bonus.

TestRail update GH

• https://github.com/Expensify/Expensify/issues/287386

Thanks all!