[Due for payment 2025-04-14] [$250] Search - Tapping an item from recent list directs blank page in mWeb & LHN in Android briefly

[IuliiaHerets]

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: V9.1.4-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
Issue reported by: Applause Internal Team
Device used: Redmi note 10s android 13
App Component: Search

Action Performed:

1. Launch app in both mweb and android
2. Tap search icon
3. Tap on an item from the recent list

Expected Result:

Tapping an item from recent list must directs to that particular page.

Actual Result:

In mweb, tapping on an item from recent list directs to blank page briefly before showing the particular item but in android LHN is shown briefly. Both android and mweb shows inconsistent behaviour.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6750867_1740232548765.Screenrecorder-2025-02-22-19-17-58-29.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021893993559253605030
• Upwork Job ID: 1893993559253605030
• Last Price Increase: 2025-03-03
• Automatic offers:
• DylanDylann | Reviewer | 106425059
• daledah | Contributor | 106425060

Issue Owner

Current Issue Owner: @trjExpensify

[melvin-bot]

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

[Krishna2323]

🚨 Edited by proposal-police: This proposal was edited at 2025-02-22 20:48:36 UTC.

Proposal

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

Search - Tapping an item from recent list directs blank page in mWeb & LHN in Android briefly

What is the root cause of that problem?

• When shouldUseNarrowLayout is true, we set the modal type to CENTERED_SWIPABLE_TO_RIGHT. This modal type is considered a fullscreen modal, so hasBackdrop will be true.
  

  App/src/components/Search/SearchRouter/SearchRouterModal.tsx

  Line 19 in 0b6d1a0

  const modalType = shouldUseNarrowLayout ? CONST.MODAL.MODAL_TYPE.CENTERED_SWIPABLE_TO_RIGHT : CONST.MODAL.MODAL_TYPE.POPOVER;

  
  

  App/src/components/Modal/BaseModal.tsx

  Line 266 in 0b6d1a0

  hasBackdrop={fullscreen}

• We only set the backdrop opacity to false when !shouldUseCustomBackdrop && hideBackdrop is true. However, in this case, hideBackdrop is false because it is only true for popovers.
  

  App/src/components/Modal/BaseModal.tsx

  Line 264 in 0b6d1a0

  backdropOpacity={!shouldUseCustomBackdrop && hideBackdrop ? 0 : variables.overlayOpacity}

• As a result, when the modal is closed, the backdrop remains visible with some opacity, making it appear like a blank page.

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

• We need to override the backdropOpacity or hasBackdrop prop, or possibly both. This can be achieved by extracting these props, passed to the BaseModal component and then pass it to backdropOpacity & hasBackdrop props.

backdropOpacity={!shouldUseCustomBackdrop && hideBackdrop ? 0 : backdropOpacity ?? variables.overlayOpacity}
hasBackdrop={hasBackdrop ?? fullscreen}

• And then pass backdropOpacity={0} & hasBackdrop={false} from SearchRouterModal.
• Additionally, we also need to wrap the navigation within setNavigationActionToMicrotaskQueue, this is because the modal requires time to finish it's animation, otherwise the blank screen will be shown.
  

  App/src/components/Search/SearchRouter/SearchRouter.tsx

  Lines 217 to 218 in 0b6d1a0

  	onRouterClose();
  	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: updatedQuery}));

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

N/A -- UI Issue

What alternative solutions did you explore? (Optional)

N/A

[Krishna2323]

PROPOSAL UPDATED

[daledah]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-05 18:23:04 UTC.

Proposal

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

• In mweb, tapping on an item from recent list directs to blank page briefly before showing the particular item but in android LHN is shown briefly. Both android and mweb shows inconsistent behaviour.

What is the root cause of that problem?

• When selecting an item from the search route modal, it triggers onRouterClose:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Line 270 in 0b6d1a0

onRouterClose();

App/src/components/Search/SearchRouter/SearchRouterModal.tsx

Line 36 in 0b6d1a0

onRouterClose={closeSearchRouter}

This sets isSearchRouterDisplayed to false before navigating to the target report screen:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Line 274 in 0b6d1a0

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));

• During the brief moment between isSearchRouterDisplayed being set to false and the navigation occurring, an empty screen appears. This happens because the search route content is only displayed when isSearchRouterDisplayed is true:
  

  App/src/components/Search/SearchRouter/SearchRouterModal.tsx

  Lines 33 to 40 in 0b6d1a0

  	{isSearchRouterDisplayed && (
  	<FocusTrapForModal active={isSearchRouterDisplayed}>
  	<SearchRouter
  	onRouterClose={closeSearchRouter}
  	shouldHideInputCaret={shouldHideInputCaret}
  	/>
  	</FocusTrapForModal>
  	)}

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

• Removing the condition isSearchRouterDisplayed in:

App/src/components/Search/SearchRouter/SearchRouterModal.tsx

Line 33 in 0b6d1a0

{isSearchRouterDisplayed && (

can fix the blank page issue.

• Now, the LHN briefly appears on both platforms when tapping an item. This happens due to the gap between closing the modal and displaying the target report.
• To minimize this delay, we can update:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Lines 270 to 278 in 0b6d1a0

	onRouterClose();
	KeyboardUtils.dismiss().then(() => {
	if (item?.reportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));
	} else if ('login' in item) {
	navigateToAndOpenReport(item.login ? [item.login] : [], false);
	}
	});

                if (item?.reportID) {
                    Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));
                } else if ('login' in item) {
                    navigateToAndOpenReport(item.login ? [item.login] : [], false);
                }
                InteractionManager.runAfterInteractions(() => { // Can use `setTimeout` with a delay time is 0 instead.
                    onRouterClose();
                });

• In this code changes:

1. I remove the KeyboardUtils.dismiss() block (optional).
2. Call onRouterClose(); when it navigates to the report screen (optional).

• For the bug:

After applying the above change, I see a minor bug: The "Search in ..." text with the search icon displays before navigating

We can add:

            if (!isSearchRouterDisplayed) {
                return undefined;
            }

in:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Line 114 in 4fabee6

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

• None

What alternative solutions did you explore? (Optional)

Result

https://github.com/user-attachments/assets/82df52c2-9a99-4cf9-9a0f-9bf70002226c8

[melvin-bot]

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

[melvin-bot]

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

[trjExpensify]

CC: @luacmartins for vis 👀

[DylanDylann]

Hi contributors, could you guys provide videos on mWeb and Android after applying your solutions?

[Krishna2323]

@DylanDylann, here's the video. In the video, you can also see that the behavior is consistent with the start chat flow.

Monosnap.screencast.2025-02-27.11-09-17.mp4

[daledah]

Proposal updated

• I just added result video.

[DylanDylann]

@daledah Thanks for your proposal. First, I think we should move isSearchRouterDisplayed check to outside instead of removing it

return isSearchRouterDisplayed && (
        <Modal
            type={modalType}
            isVisible={isSearchRouterDisplayed}
            innerContainerStyle={{paddingTop: safeAreaInsets.top + viewportOffsetTop}}
......

And we shouldn't remove the dismiss function

                KeyboardUtils.dismiss().then(() => {
                    if (item?.reportID) {
                        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));
                    } else if ('login' in item) {
                        navigateToAndOpenReport(item.login ? [item.login] : [], false);
                    }
                });
                InteractionManager.runAfterInteractions(() => { 
                    onRouterClose();
                });

After applying the above change, I see a minor bug: The "Search in ..." text with the search icon displays before navigating

Screen.Recording.2025-03-03.at.12.31.52.mov

[DylanDylann]

@Krishna2323 Thanks for your proposal. But I prefer @daledah's solution because it solves this problem completely

[melvin-bot]

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

[Krishna2323]

@DylanDylann Thanks for the review. Can you please explain what's missing in my proposal?

[daledah]

@DylanDylann I updated the proposal to fix the issue you mentioned in comment.

[melvin-bot]

@DylanDylann Whoops! This issue is 2 days overdue. Let's get this updated quick!

[DylanDylann]

@daledah's proposal looks good to me

🎀 👀 🎀 C+ Reviewed

[DylanDylann]

@DylanDylann Thanks for the review. Can you please explain what's missing in my proposal?

@Krishna2323 Your proposal also can solve this problem, but I lean toward @daledah's proposal

[daledah]

@DylanDylann PR is ready.

[trjExpensify]

Checklist time for tomorrow, @DylanDylann.

[trjExpensify]

Bump on the checklist! =D

[DylanDylann]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] 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:

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source 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:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[DylanDylann]

The PR is still being reviewed. The previous PR was reverted

[trjExpensify]

Removed the payment holds.

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

• fix: Tapping an item from recent list directs blank page #58878

If no regressions arise, payment will be issued on 2025-04-14. 🎊

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

• @DylanDylann requires payment automatic offer (Reviewer)
• @daledah requires payment automatic offer (Contributor)

[melvin-bot]

@DylanDylann @trjExpensify @DylanDylann The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[trjExpensify]

👋 Alright, payment summary as follows:

• $250 to @DylanDylann for C+
• $250 to @daledah for the PR

[DylanDylann]

There was one regression it seems

@trjExpensify I would like to say no because the second PR is the same as the previous PR. The regression seems not to be from our change and it seems a mistake elsewhere

[DylanDylann]

cc @daledah @luacmartins

[trjExpensify]

Hm, I'm confused. 😕

#58878 - why does this PR title say "and fix regressions" and tags the blockers that were created causing us to revert it? Where else were they fixed, if not in this PR. 🤔

Comment ref:

@daledah @DylanDylann we reverted this PR because it caused two blockers. @daledah please work on a new PR taking those into account:

#58726
#58742

[DylanDylann]

@daledah please update the title of the second PR. To be honest, we didn't change anything and didn't fix any regression

[trjExpensify]

Where were those bugs fixed then? 😅

[daledah]

Initially we thought that the deploy blockers was from the original PR. But after opening the second PR, I could not reproduce the deploy blockers anymore with code changes from the PR above, so I mentioned it here and reverted the additional changes in this PR.

Basically the second PR reimplements the first PR and regression comes from another PR and is fixed now.

[trjExpensify]

Interesting, okay. Edited the payment summary to $250. Paid and closing!