[HOLD for payment 2024-02-01] [$500] mWeb - Clicking back button takes user to wrong page from avatar preview page

[kbecciv]

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. Go to settings > profile
2. Click on avatar and add a photo if you don't have any
3. Click on the avatar again
4. Click on View photo
5. Click on the system/browser back button

Expected Result:

App should take user back to profile page

Actual Result:

App takes user to settings page

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: 1.3.72.6
Reproducible in staging?: y
Reproducible in production?: new feature
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

Screen_Recording_20230920_112520_Chrome.mp4

Screen_Recording_20230920_080235_Chrome.mp4

Expensify/Expensify Issue URL:
Issue reported by: @Nathan-Mulugeta
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695198495998809

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014e3810eaf600caf1
• Upwork Job ID: 1704467134489030656
• Last Price Increase: 2023-09-27
• Automatic offers:
• aimane-chnaif | Reviewer | 27020346
• dukenv0307 | Contributor | 27020347
• Nathan-Mulugeta | Reporter | 27020348

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~014e3810eaf600caf1

[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 @CortneyOfstad (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[melvin-bot]

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

[dukenv0307]

Proposal

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

App takes user to settings page

What is the root cause of that problem?

When we click View photo, we only open the attachment modal, without navigating to any new page, so when clicking the system back button, it will go back to the previous page (Settings)

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

We should put the attachment modal in a new route similar to the report attachments

(Example report attachment route: /r/6416318141873324/attachment?source=/chat-attachments/3998623682118365637/w_cc41cdd25a901a0db6f2d14abc88d8c828b81089.jpg)

The new route can look something like /settings/profile/attachment?source=...

Then navigate to that route when clicking View photo, similar to here

What alternative solutions did you explore? (Optional)

It doesn't have to be a new route, if we want to keep the current route, adding source= params or hash to the current route will also work fine.

[CortneyOfstad]

Was able to recreate. @aimane-chnaif, thoughts on the proposal above?

[lcsvcn]

Proposal

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

App takes user to settings page

What is the root cause of that problem?

When we click View photo, we open the attachment modal. When the user clicks with the hardware (now virtual) back press button present on all Android phones, it will go to last URL page by default to in any browser.

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

To address the issue, we propose implementing improvements within the AttachmentModal component, which currently lacks support for handling hardware back button presses. Our solution involves the following steps:

Integrate a Hardware Back Button Library: We recommend incorporating a library that allows us to monitor hardware back button presses. A suitable choice is the BackPressed library, which provides essential functionality for detecting these events.

Recognition of Back Button Presses: With the library integrated, we can proceed to implement logic that recognizes when a hardware back button press occurs while the modal is open. This recognition should be limited to instances when the modal is visible to prevent unintended interference with the default hardware back button behavior.

Modal Closure on Back Press: Upon detecting a back button press while the modal is open, our code will execute actions to promptly close the modal. This action ensures that the modal behaves as expected when the user presses the back button.

Conditional Override of Default Behavior: Importantly, our implementation will override the default hardware back button behavior only when the modal is currently displayed. In all other circumstances, the default behavior of the hardware back button remains unchanged.

By following these steps and incorporating this solution into the AttachmentModal component, we can ensure that the modal effectively responds to hardware back button presses while maintaining a consistent user experience. This solution not only addresses the current issue but also enhances the component's behavior for all code that utilizes it.

For the actual implementation within your AttachmentModal component, please refer to the provided code example in the previous response.

From the actual code:

App/src/components/AttachmentModal.js

Line 102 in 4c207ec

const [isModalOpen, setIsModalOpen] = useState(props.defaultOpen);

App/src/components/AttachmentModal.js

Lines 314 to 323 in 4c207ec

	const closeModal = useCallback(() => {
	setIsModalOpen(false);
	}, []);
	/**
	* open the modal
	*/
	const openModal = useCallback(() => {
	setIsModalOpen(true);
	}, []);

So we could implement something like the below:

useEffect(() => {
    const backHandler = BackHandler.addEventListener(
      'hardwareBackPress',
      () => {
        if (isModalOpen) {
          closeModal();
          return true; // Prevent default behavior (navigating back)
        }
        return false; // Allow default behavior (navigating back)
      }
    );

    return () => {
      backHandler.remove();
    };
  }, [isModalOpen]);

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

@NicMendonca, @aimane-chnaif Whoops! This issue is 2 days overdue. Let's get this updated quick!

[NicMendonca]

@aimane-chnaif proposals here for you! ^

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@NicMendonca, @aimane-chnaif Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[aimane-chnaif]

reviewing today

[NicMendonca]

@aimane-chnaif any updates?

[melvin-bot]

@NicMendonca @aimane-chnaif this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[dukenv0307]

@aimane-chnaif The PR is ready for review

[melvin-bot]

This issue has not been updated in over 15 days. @johnmlee101, @NicMendonca, @aimane-chnaif, @dukenv0307 eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[NicMendonca]

@aimane-chnaif @dukenv0307 what's the latest on this one?

[dukenv0307]

@NicMendonca The PR is still reviewing.

[melvin-bot]

@johnmlee101, @NicMendonca, @aimane-chnaif, @dukenv0307, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

[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.4.31-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• The app should take the user back to the profile page when the user clicks the back button in the web browser #28999

If no regressions arise, payment will be issued on 2024-02-01. 🎊

For reference, here are some details about the assignees on this issue:

• @aimane-chnaif requires payment automatic offer (Reviewer)
• @dukenv0307 requires payment automatic offer (Contributor)
• @Nathan-Mulugeta requires payment automatic offer (Reporter)

[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:

• [@aimane-chnaif] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif] 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:
• [@aimane-chnaif] 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:
• [@aimane-chnaif] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] 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.
• [@NicMendonca] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[dukenv0307]

@NicMendonca Please help to re-open this issue, the PR is deployed to production.

[NicMendonca]

why was it closed 😕

[NicMendonca]

I am going on leave starting tomorrow, so just paid everyone out today!