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

Proposal

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

After off select mode on mWeb at Search page with some reports(under 6 but different to screen Y size), Search type menu and status bar is hidden.

What is the root cause of that problem?

Because it has no left screen to scroll, Search menu's top stays at -26(it stays above screen) on mWeb. The reason the menu gets hidden is scrollHandler which decide menus top position. This method is added because this red part takes much space so when scroll down a user can see more report then before:

However scrollHandler doesn't act since there is no left screen to scroll. So Search menu's top keeps -26.

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

We can make Search menu's top: 80 when it is hidden while selection mode. We can get if it's selection mode by selectionMode. While on selection mode, set it's top behind. We can get Search menu's top by topBarOffset.value.:

If both condition is matched then make Search menu's top: 80. So we add this code:

         if(selectionMode && topBarOffset.value < 80) {
           topBarOffset.value = variables.searchHeaderHeight
         }          

So after off selectionMode and if the menu's top hides a bit, then the menu shows.

What alternative solutions did you explore? (Optional)

N/A

@muttmuure Huh... This is 4 days overdue. Who can take care of this?

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

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

Proposal

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

The top part (dropdown button, filter button, status) is blank when scrolling up after deleting expense.

What is the root cause of that problem?

We control the topBarOffset of the top bar based on the scroll event.

This bug happens if the top bar is hidden and the content is reduced to less than the window height after we delete the expense. In this case, the scroll event isn't triggered and the topBarOffset is still the value when the top bar is hidden.

That is how the bug happens

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

We should check if the content size is reduced to a non-scrollable, we need to update topBarOffset to variables.searchHeaderHeight. We can capture the content size is changed from onContentSizeChange event of SelectionList

1. Introduce a new prop onContentSizeChange in BaseSelectionList and Search. Pass this event here and here

2. Add onContentSizeChange here and update topBarOffset if the content size height is less than the window height

onContentSizeChange={(w, h) => {
    if (windowHeight <= h) {
        return;
    }
    topBarOffset.value = withTiming(variables.searchHeaderHeight, {duration: ANIMATION_DURATION_IN_MS});
}}

What alternative solutions did you explore? (Optional)

@mkzie2's proposal LGTM

🎀👀🎀 C reviewed

Triggered auto assignment to @dangrous, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

LGTM!

📣 @mkzie2 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

Reviewing label has been removed, please complete the "BugZero Checklist".

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:

• fix: search page top bar is hidden after deleting an expense #53072

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

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

• @dukenv0307 requires payment through NewDot Manual Requests
• @mkzie2 requires payment automatic offer (Contributor)

@dukenv0307 @muttmuure @dukenv0307 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]

@dukenv0307 - $250 C
@mkzie2 - $250 C

@dangrous, @muttmuure, @dukenv0307, @mkzie2 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

$250 approved for @dukenv0307

BugZero Checklist:

• [Contributor] Classify the bug:

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

@dukenv0307/ @mkzie2 can you complete the checklist to clear this out?

@dangrous, @muttmuure, @dukenv0307, @mkzie2 Huh... This is 4 days overdue. Who can take care of this?