Skip to content

Expense - Unable to interact with the "Review duplicates" button for a short time #58466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 8 tasks
jponikarchuk opened this issue Mar 14, 2025 · 5 comments
Closed
2 of 8 tasks
Assignees
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2

Comments

@jponikarchuk
Copy link

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: 9.1.13-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: #57197
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Windows 10 / Chrome, macOS Sequoia 15.0
App Component: Money Requests

Action Performed:

  1. Navigate to https://staging.new.expensify.com/
  2. Log in with a new Gmail account
  3. Create a workspace
  4. Navigate to the workspace chat
  5. Create 2 manual expenses with the same amount, currency and merchant
  6. Click on the combined expenses
  7. Click on any of the expenses
  8. Click on the "Got it" button on the "This request is on hold" modal and quickly click on the "Review duplicates" button after

Expected Result:

I should be able navigates to the "Review duplicates" RHP.

Actual Result:

Unable to interact with the "Review duplicates" button for a short time after dismissing the "This request is on hold" modal.

Workaround:

Unknown

Platforms:

  • Android: Standalone
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: Standalone
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
  • MacOS: Desktop

Screenshots/Videos

Bug6770384_1741933049097.bandicam_2025-03-14_07-11-57-794.mp4

View all open jobs on GitHub

@jponikarchuk jponikarchuk added Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2 labels Mar 14, 2025
Copy link

melvin-bot bot commented Mar 14, 2025

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

@bernhardoj
Copy link
Contributor

Proposal

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

The review duplicates button aren't pressable for a short time after closing the hold educational modal.

What is the root cause of that problem?

It's not that the review duplicates aren't responsible, but the whole page is covered by the modal. When the hold educational modal is shown, it's a separate full screen page. When we close it, the page won't immediately close and instead wait until the modal animation is done.

setIsModalVisible(false);
InteractionManager.runAfterInteractions(() => {
Navigation.goBack();
onClose?.();
});

However, since the navigation back code is wrapped with InteractionManager.runAfterInteractions (a promise), it's further delayed.

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

Instead of using InteractionManager.runAfterInteractions, we can call the navigation back (and onClose) from the Modal onModalHide. The page will still close after the modal animation is done, but no promise anymore.

onModalHide={() => {
    Navigation.goBack();
    onClose?.();
}}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

@melvin-bot melvin-bot bot added the Overdue label Mar 17, 2025
@joekaufmanexpensify
Copy link
Contributor

Not overdue. Going to triage today.

@melvin-bot melvin-bot bot removed the Overdue label Mar 17, 2025
@joekaufmanexpensify
Copy link
Contributor

I can reproduce this. However, I am dubious that any real customer would ever experience this. You need to intentionally go out of your way to find this and quickly try and resolve the duplicates immediately after closing the modal. If you wait a normal amount of time after closing the modal, there is no issue clicking the button to resolve duplicates.

I recommend we wait to see if any real customer experiences this before changing this behavior.

@joekaufmanexpensify
Copy link
Contributor

Closing this for now, but let me know if anyone disagrees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is broken. Auto assigns a BugZero manager. Daily KSv2
Projects
None yet
Development

No branches or pull requests

3 participants