[HOLD for payment 2024-12-11] Android - Search - Saved search items overlap with navigation bar

[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: 9.0.67-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• Device navigation is buttons instead of swipe gestures.
• Account has many saved searches.

1. Launch ND or hybrid app.
2. Go to Search.
3. Tap on the dropdown.
4. Scroll down.

Expected Result:

Saved search items will not overlap with device navigation bar.

Actual Result:

Saved search items overlaps with device navigation bar.

This issue is not reproducible if device navigation uses swipe gestures.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6677728_1732692121109.Screen_Recording_20241127_151421.mp4

View all open jobs on GitHub

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.

[melvin-bot]

Triggered auto assignment to @techievivek (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[kirillzyusko]

It happened because of this PR: #52392

[techievivek]

@kirillzyusko Are you working on the fix for this? Should we demote it?

[mountiny]

I can take over, I think we should look into fixing this now as its bad UI/UX, but I would only demote if deploy is getting longer

[techievivek]

Sounds good, thanks.

[kirillzyusko]

The iOS also has the same behavior:

What edge-to-edge PR did -> it unified both platforms (now iOS and Android should work in the same way).

I agree that it doesn't look good, but iOS has been working in such way for a long time 🤔 I think at least we should ask UX/UI team opinion (whether we need to apply a bottom padding) and I think we should remove deploy blocker label (because it's not an issue - Android just started to be more similar to iOS).

@mountiny what do you think?

[mountiny]

I agree its not a blocker as you can click the android buttons, but I would say its not same to compare ios with just a bar on which you always just swipe up to buttons like you can see in the android recording that you have to tap and you can mistap and click on the item behind it

So I am demoting, but lets add a safe area to the android devices that have the buttons in the bottom. I dont feel like this is a problem on ios as you just have the bar on swich you swipe up. But I think we should check what are the ios guidelines on the safe area and follow those

[mountiny]

@kirillzyusko I put other two issues on hold for this that have same root cause so lets handle it here

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[mountiny]

The PR that should address this is up

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

• feat: new way to handle insets in the app #53250

If no regressions arise, payment will be issued on 2024-12-11. 🎊

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

• @kirillzyusko does not require payment (Contractor)

[melvin-bot]

@mountiny @trjExpensify @kirillzyusko 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]

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[trjExpensify]

I think that's incorrect, Melvin. @ZhenjaHorbach reviewed the PR. Can we get the checklist here, please?

[ZhenjaHorbach]

I'll do it today !

[ZhenjaHorbach]

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.

  It's regression and this bug was fixed by the person who made the PR

• [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.

  NA

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

Test:

1. Launch ND or hybrid app.
2. Go to Search.
3. Tap on the Expenses dropdown.
4. Scroll down.
5. Verify that Saved search items will not overlap with device navigation bar.

Do we agree 👍 or 👎

[trjExpensify]

Given that Applause caught this visual bug, I'm inclined to skip adding a standalone regression test for it. Happy for a second opinion on that from @mountiny @techievivek.

In the meantime, confirming payments as follows:

• $250 to @ZhenjaHorbach for the C+ review

Offer sent!

[trjExpensify]

Paid!

[mountiny]

definitely no test

[trjExpensify]

Definitely closing then!