Android - Search field is partially visible when entering search term when scrolled down

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.60-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93877
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Workspace Settings

Action Performed:

1. Launch Expensify app.
2. Go to workspace settings > Categories.
3. Tap on the search field.
4. Scroll down the list.
5. Enter anything that will return search results.

Expected Result:

Search field will be completely visible when entering search term when scrolled down.

Actual Result:

Search field is partially visible when entering search term when scrolled down.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7241781_1787609320888.Screen_Recording_20260825_060655_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7241781

Issue Owner

Current Issue Owner: @KJ21-ENG

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/cea64a57dd7b8bc1e0bb68f0ce29185f1ae1fefe52ccaef5261ca75aa80bade5

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #93877

[melvin-bot]

@Krishna2323 @JS00001 you have been assigned to this deploy blocker because you reviewed the offending PR: #93877

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (fix belongs in Expensify/App)
Causing PR: #93877 - "Update table pages to scroll full page" by KJ21-ENG (High confidence)
Related Issues: none

Recommendation: ROLL FORWARD (targeted fix — do not revert)

#93877 is a large, foundational refactor (75 files) that migrated ~20 workspace/table pages to a single scrolling FlashList with a sticky column header and a new native "scroll the search input above the keyboard" behavior. Reverting would be highly disruptive and would reintroduce everything it fixed, so the right move is a targeted fix to the scroll-into-view math rather than a revert.

Assigned: KJ21-ENG (PR author), JS00001 (approver / merger), Krishna2323 (approver) — from the single highest-confidence causing PR (#93877)
Labels: No changes. DeployBlockerCash is correctly retained (Frontend bug, App deploy blocked). No DeployBlocker was present. Not reproducible in production, so the App blocker must stay regardless.

📋 Detailed Analysis

Evidence

• Timeline matches: Update table pages to scroll full page #93877 merged 2026-08-24 18:13 UTC into staging 9.4.60-0; this bug was reported the same day (22:51 UTC) on 9.4.60-0, is reproducible in staging, and is not reproducible in production — i.e. introduced in this exact release. Update table pages to scroll full page #93877 is listed in the current StagingDeployCash.
• Scope matches: The PR's own description says it migrates Categories (and all workspace tables) so "page-level controls (header content, buttons, search/filter bar) render inside the table's FlashList and scroll away with the rows, while the table column header is rendered as a sticky list item." It also explicitly adds: "on native, focusing the table search bar now scrolls it above the keyboard (using the existing useScrollToFocusedInput pattern), so the input stays visible while typing." That newly-added behavior is exactly the flow that is misbehaving.
• Platform matches: The symptom is Android App only. The offending scroll behavior lives in a .native.ts file (useScrollToFocusedInput/index.native.ts) that only runs on native, consistent with the platform scoping of the report. PR test step 7 covers exactly this ("tap the search bar … verify the list scrolls the search input above the keyboard and it stays fully visible while typing").

Verification

• Affected feature = the search field on the Workspace > Categories list (a migrated table page).
• git log on src/components/Table/TableFilterBar/TableSearchBar.tsx shows the file was introduced/rewritten as part of the table migration, and the search input's onFocus now calls the new scroll helper.
• Confirmed Update table pages to scroll full page #93877 modifies the exact files in the code path:
  • src/components/Table/TableFilterBar/TableSearchBar.tsx (+35/-4)
  • src/components/Table/TableBody.tsx (+354/-36) — wires useScrollToFocusedInput into the list
  • plus src/components/Tables/WorkspaceCategoriesTable/index.tsx and src/pages/workspace/categories/WorkspaceCategoriesPage.tsx
• The useScrollToFocusedInput native hook (import useScrollToFocusedInput from '@components/SelectionList/hooks/useScrollToFocusedInput') is newly consumed by TableBody in this PR.

Root Cause

The search input's onFocus handler now triggers a scroll-into-view routine added by this PR:

src/components/Table/TableFilterBar/TableSearchBar.tsx (staging tip):
L111-L115

onFocus={() => {
    setInputFocused(true);
    // Keep the input visible above the keyboard when it is focused inside the scrolling table list.
    scrollInputIntoView(inputRef.current);
}}

src/components/SelectionList/hooks/useScrollToFocusedInput/index.native.ts:
L58-L113

container.measureInWindow((containerX, containerY) => {
    input.measureInWindow((inputX, inputY) => {
        const target = containerY + EXTRA_SCROLL_PADDING;   // anchors to the list container TOP
        const delta = inputY - target;
        if (delta <= 0) {                                   // only scrolls when input is BELOW the anchor
            return;
        }
        list.scrollToOffset({offset: scrollOffsetRef.current + delta, animated: true});
    });
});

The routine anchors the focused input to the top of the list container (containerY + EXTRA_SCROLL_PADDING) and only scrolls when the input is below that anchor (delta > 0). When the list is scrolled down and the search bar is scrolled inside the FlashList, the sticky column header (also introduced by this PR) occupies the top of the container. The anchor calculation does not subtract the sticky header's height, so the input is pulled up to a position that is partially occluded by the sticky header — producing the reported "search field is only partially visible when entering a search term while scrolled down." The delta <= 0 early-return also means an input already near the top (but partly hidden under the sticky header) is never nudged fully into view.

Suggested targeted fix (for the assignees)

Offset the scroll anchor by the sticky table-header height (and/or measure against the true visible viewport top rather than the growing container top) so the focused search input lands fully below the sticky header instead of behind it. This is contained to useScrollToFocusedInput/index.native.ts and does not require touching the broader table migration.

---

view run

[JS00001]

@KJ21-ENG I'll demote this, but lets fix in a follow up