[Due for payment 2026-09-09] Android & iOS - Copilot - Copilot - Clear button dismisses keyboard instead of clearing search

[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.65-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #98603
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: iPhone 15 Pro Max / iOS 26.6.1
App Component: User Settings

Action Performed:

Precondition:

• Have access to 13 accounts with copilot access.

1. Launch Expensify app.
2. Go to Account.
3. Open account switcher.
4. Tap on the search field.
5. Type anything.
6. With keyboard open, tap clear button.

Expected Result:

Search field will be cleared.

Actual Result:

Clear button dismisses keyboard instead of clearing search field.

The same issue also happens when user taps on the account with keyboard open, keyboard dismisses instead of switching to another account directly.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7247539_1788202870929.ScreenRecording_09-01-2026_02-59-30_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7247539

Issue Owner

Current Issue Owner: @eh2077

[melvin-bot]

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

[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/95d626096c5b0772b42e5af507cb7883674abf0646bdeaeb266ffcbf07932dad

[melvin-bot]

@youssef-lr @JmillsExpensify @eh2077 you have been assigned to this deploy blocker because you reviewed the offending PR: #98603

[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
Causing PR: #98603 - "Fix missing search inputs for Copilot lists" by @emkhalid (High confidence)
Related Issues: #96225 (the issue #98603 was fixing), #99948 (StagingDeployCash)

Recommendation: REVERT

PopoverMenu's scroll container has never carried keyboardShouldPersistTaps, and #98603 is the first and only PR to put a focused TextInput inside a PopoverMenu, so it directly exposed a native touch-swallowing path. The one-line keyboardShouldPersistTaps fix covers the "tap an account row" half of the report but not the clear-button half (the search bar renders outside that ScrollView), so a roll-forward needs on-device verification on both iOS and Android — reverting is the safer call inside the deploy window, and costs nothing user-facing because the feature is not in production yet.

Assigned: @emkhalid (PR author), @eh2077, @JmillsExpensify, @youssef-lr (approving reviewers) from highest-confidence causing PR only
Labels: No changes. DeployBlockerCash is kept (App-side fix required). DeployBlocker was never applied, so nothing to remove.

📋 Detailed Analysis

Evidence

• The reported surface is the account switcher search field, which only exists because of Fix missing search inputs for Copilot lists #98603. searchInputLabel — the prop that turns on PopoverMenu's search mode — has exactly one consumer in the codebase: AccountSwitcher.tsx#L343-L347. (CurrencyPicker passes a same-named prop to CurrencySelectionList, an unrelated component.)
• The 13-account precondition in the repro matches the gate the PR added: shouldShowSearchInput = !isActingAsDelegate && delegatorMenuItems.length >= CONST.STANDARD_LIST_ITEM_LIMIT, and STANDARD_LIST_ITEM_LIMIT: 12.
• Fix missing search inputs for Copilot lists #98603 merged 2026-08-29 and is item 8 on the current deploy checklist Deploy Checklist: New Expensify 2026-08-31 #99948. The bug is staging-only ("N/A - new feature, doesn't exist in prod"), consistent with a PR in this deploy.
• The symptom pattern — the first tap anywhere in the sheet is swallowed while the soft keyboard is up, native only, and the sheet does not close — is the signature of React Native's ScrollResponder, not of a backdrop press. A backdrop tap would dismiss the whole popover; instead only the keyboard goes away.

Verification

Files checked against the checked-out source at f6a4920:

Claim	Location
Menu items render in a bare ScrollView with no keyboardShouldPersistTaps	PopoverMenu/index.tsx#L256-L264
Search bar is rendered as a sibling above that ScrollView, not inside it	PopoverMenu/index.tsx#L786-L807
PR switches the popover onto the avoidKeyboard code path	PopoverMenu/index.tsx#L755-L756
avoidKeyboard swaps the modal's child wrapper for a KeyboardAvoidingView (behavior="padding") on native	ReanimatedModal/index.tsx#L248-L255
The comparable pattern elsewhere does set it	SelectionList/BaseSelectionList.tsx#L515 uses keyboardShouldPersistTaps="always"

The ScrollView line itself is not in the #98603 diff — it is pre-existing PopoverMenu code. But it was unreachable-with-a-keyboard until this PR, because PopoverMenu had no text input before it. That is what makes this "newly exposed by #98603" rather than "newly written by #98603", and it is why the fix belongs in PopoverMenu, not in AccountSwitcher.

Root Cause

Symptom 2 (tap an account row → keyboard dismisses instead of switching) — confirmed:

PopoverMenuContent renders the menu items in @components/ScrollView, which forwards straight to RN's ScrollView without a keyboardShouldPersistTaps prop, so RN applies its default of 'never'. With that default, ScrollResponder's onStartShouldSetResponderCapture claims the first touch inside the scroll view whenever the soft keyboard is open, dismisses the keyboard, and never delivers the touch to the child MenuItem. This is JS-level ScrollResponder behavior, so it reproduces identically on Android and iOS and not on web — exactly matching the platform checkboxes on this issue.

Symptom 1 (clear "X" button → keyboard dismisses instead of clearing) — same PR, different layer:

This one is not explained by the ScrollView, because the SearchBar is rendered outside it at PopoverMenu/index.tsx#L786-L798. The clear button itself is sound — TextInputClearButton is a plain PressableWithoutFeedback whose only "don't steal focus" guard is onMouseDown: e.preventDefault(), which is web-only and has no native counterpart. The remaining suspect is the native layout/hit-test path the PR newly turned on: avoidKeyboard swaps the modal child for a KeyboardAvoidingView with behavior="padding" inside a bottom-docked modal whose container is overflow: 'hidden'. The PR author already had to patch one native shrink-wrap symptom on that path (outerStyle/styles.w100, with the comment "The native KeyboardAvoidingView can shrink-wrap a bottom-docked modal"), which is direct evidence this path is fragile on device. I could not pin this half to a single line by static reading, and it needs a device repro to confirm.

Why revert over a targeted fix: two distinct native touch defects live in the same brand-new path; the obvious one-liner only fixes one of them; and #98603 additionally changes shared PopoverMenu and ReanimatedModal backdrop code used by every modal in the app, so the blast radius of leaving it on staging is wider than the Copilot feature itself. Note that #97031 also touched PopoverMenu/index.tsx after this PR merged, so expect a small conflict in the revert.

If @emkhalid prefers to roll forward and can verify on a physical/simulated iOS and Android device within the deploy window, the starting patch is:

   if (shouldUseScrollView) {
       return (
           <ScrollView
+              keyboardShouldPersistTaps="handled"
               contentContainerStyle={contentContainerStyle}
               addBottomSafeAreaPadding={shouldAddBottomSafeAreaPadding}
           >

…but that alone will not fix the clear button, so please re-test step 6 of the repro specifically, not just the account-row tap.

---

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: UI-4 — Scrollables that coexist with a text input must set keyboardShouldPersistTaps
• Condition: When a change puts a TextInput/SearchBar into a component (or into a modal/popover) that also renders ScrollView/FlatList/SectionList/FlashList, that scrollable must set keyboardShouldPersistTaps="handled" (or "always"). RN defaults to 'never', which makes the scroll view eat the first tap on native whenever the soft keyboard is open.
• Why: ScrollResponder's capture handler dismisses the keyboard and swallows the touch, so the user's first tap on any row or button inside the list silently does nothing — a native-only regression that never shows up in web testing. This deploy blocker ([Due for payment 2026-09-09] Android & iOS - Copilot - Copilot - Clear button dismisses keyboard instead of clearing search #99964) is the incident.
• Search pattern: in a diff that adds <TextInput, <SearchBar, or a searchInput* prop, grep the same component tree for <ScrollView/<FlatList/<SectionList/<FlashList and flag any occurrence with no keyboardShouldPersistTaps=. Repo-wide sweep: rg -n '<(ScrollView|FlatList|SectionList|FlashList)\b' -A 8 src/ | rg -v 'keyboardShouldPersistTaps'.
• Offending code (❌): src/components/PopoverMenu/index.tsx#L256-L264
• Fix (✅): the same ScrollView with keyboardShouldPersistTaps="handled", matching BaseSelectionList.tsx#L515

The full rule file, with the ❌/✅ code inline in Expensify/App's coding-standards format, would go in Expensify/App itself (.claude/skills/coding-standards/rules/ui-4-*.md plus a SKILL.md bullet under UI). If it's worth adding, a maintainer can open it there as a draft PR. I have not modified any coding-standards file.