[$500] Web - Navigation breaks on opening attachment, reload and opening search by shortcut

[izarutskaya]

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 any report
3. Send any attachment
4. Open the attachment
5. Reload
6. Click CTRL+K/CMD+K to open search and observe that URL changes but app still displays image
7. Close the attachment and observe that URL still shows attachment URL but app displays the report

Expected Result:

App should close the image attachment when we open search page using shortcut

Actual Result:

App does not close the image attachment when we open attachment, reload and open search page using shortcut and it breaks the further navigation

Workaround:

Unknown

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: Build v1.3.74-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

attachment.preview.search.breaks.navigation.windows.chrome.mp4

Recording.1641.mp4

Expensify/Expensify Issue URL:

Issue reported by: @dhanashree-sawant

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695575577105459

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d3cee7fe8b187729
• Upwork Job ID: 1706594842812719104
• Last Price Increase: 2023-10-03
• Automatic offers:
• dukenv0307 | Contributor | 27004795
• dhanashree-sawant | Reporter | 27004799

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[dukenv0307]

Proposal

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

App does not close the image attachment when we open attachment, reload and open search page using shortcut and it breaks the further navigation

What is the root cause of that problem?

Here, when the PopoverWithoutOverlay is rendered the first time, it always set the closeModal function to null, which overrides the closeModal function that is set by the attachment modal when the attachment modal is first rendered. So it fails to close the attachment modal when using the shortcut here.

This is not correct since this useEffect block should only trigger when isVisible change, not at the first render. This is also explained in the comment here.

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

We should make sure this line is only triggered when isVisible changes.

1. Store previous value of isVisible by using the usePrevious

const prevIsVisible = usePrevious(props.isVisible);

2. Make sure isVisible changes before triggering Modal.setCloseModal above this line, by early return if isVisible did not change.

if (prevIsVisible === props.isVisible) {
    return;
}

or that can be put here if we want to exclude the full logic of the useEffect

What alternative solutions did you explore? (Optional)

An alternative is to use isFirstRender approach to not run the useEffect if it's the first render of the PopoverWithoutOverlay component.

[parasharrajat]

This Modal.setCloseModal logic has been always confusing for me. Can we somehow remove it?

May be the use of a Context to trigger close to all modals not just the latest. @dukenv0307 ideas?

---

About the proposal:

I am curious wouldn't the useEffect itself detect changes to passed dependency? IMO, this this useEffect should only run isVisible changes. So there should be no need to manually check that.

[dukenv0307]

I am curious wouldn't the useEffect itself detect changes to passed dependency? IMO, this this useEffect should only run isVisible changes. So there should be no need to manually check that.

@parasharrajat yes, but useEffect will always run on first render as well. So by default it will run:

• on first render
• after any dependency changes

(This is different from componentDidUpdate that we uses earlier which only runs after dependency changes, this has caused quite a number of issues since we migrated to hooks, usePrevious was added to fix those issues)

Also we have the same fix using wasVisible for the BaseModal as well here

[dukenv0307]

May be the use of a Context to trigger close to all modals not just the latest. @dukenv0307 ideas?

@parasharrajat Yes we can maybe use a Context to pass a shouldForceClose boolean to all Modals and if we want to close them we just set shouldForceClose to true. But we only have 1 modal opens at a time so I think closing all modals are the same as closing the latest, so maybe the isVisible check if sufficient for this issue.