Skip to content

Report field - Clear button on search does not clear input when keyboard is opened #103918

Closed
Closed
Report field - Clear button on search does not clear input when keyboard is opened#103918
Assignees
AndrewGable
Labels
BugSomething is broken. Auto assigns a BugZero manager.EngineeringHourlyKSv2ReviewingHas a PR in review

Description

@applause-bot
applause-bot
bot
opened on Oct 13, 2026

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

Version Number: 9.5.8-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: #102142
Email or phone of affected tester (no customers): jsoidjndoiniodnsjojd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 17 Pro Max / iOS 27.0.1
App Component: Money Requests

Action Performed:

Precondition:

  • Enable Report fields.
  • Create a list report field with at least 8 list values.
  1. Launch Expensify app.
  2. Go to workspace chat.
  3. Create an empty report.
  4. Open the report.
  5. Tap on the list report field.
  6. Tap on the search field.
  7. Type anything on the search field.
  8. While keyboard is opened, tap clear button on search field.

Expected Result:

Clear button on search field will clear the input when keyboard is opened.

Actual Result:

Clear button on search field closes the keyboard and does not clear input when keyboard is opened.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7285298_1791895928426.ScreenRecording_10-13-2026_20-48-36_1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7285298

Activity

  1. applause-bot
    added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Oct 13, 2026
  2. gleitebr
    added this to #expensify-bugson Oct 13, 2026

  3. applause-bot commented on Oct 13, 2026

    @applause-bot
    applause-botBot
    on Oct 13, 2026
    Author

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

  4. melvin-bot
    assigned
    AndrewGable
    on Oct 13, 2026

  5. melvin-bot commented on Oct 13, 2026

    @melvin-bot
    melvin-botBot
    on Oct 13, 2026 – with Melvin Bot

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

  6. melvin-bot commented on Oct 13, 2026

    @melvin-bot
    melvin-botBot
    on Oct 13, 2026 – with Melvin Bot

    @AndrewGable you have been assigned to this deploy blocker because you reviewed the offending PR: #102142

  7. melvin-bot commented on Oct 13, 2026

    @melvin-bot
    melvin-botBot
    on Oct 13, 2026 – with Melvin Bot

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

  8. github-actions
    added
    Engineering
    HourlyKSv2
    on Oct 13, 2026

  9. github-actions commented on Oct 13, 2026

    @github-actions
    github-actionsBot
    on Oct 13, 2026 – with GitHub Actions
    Contributor

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

  10. MelvinBot commented on Oct 13, 2026

    @MelvinBot
    MelvinBot
    on Oct 13, 2026
    Contributor

    Deploy Blocker Analysis

    Causing PR: Restore: Show up to three report fields per row and edit them inline (high confidence). The auto-assignment is correct.

    Root cause: On an empty report, a list field now opens an inline dropdown instead of a separate page. That dropdown sits inside a ScrollView that doesn't set keyboardShouldPersistTaps (MoneyRequestReportEmptyStateView.tsx:31). With the keyboard open, the first tap on the clear button only dismisses the keyboard. The button never gets the press.

    Recommended resolution: Revert the PR on staging. It is the shared cause of four other open blockers:

    If the team rolls forward instead, this bug needs one line: add keyboardShouldPersistTaps="handled" to that ScrollView. Reports with expenses already do this (MoneyRequestReportUnifiedList.tsx:399). That fix doesn't help the other four blockers.

    Investigation details

    Code is cited at staging commit 9ffd50a1.

    1. Production: tapping a list report field opened the editor as a full page. The search input was never inside the report's ScrollView.
    2. Staging: the PR opens an inline dropdown that holds the same list. The list shows a search input once it has 8 or more values, which matches the issue's precondition (ReportFieldInlineInput.tsx:205-245). The dropdown is a React Native Modal (FilterPopupButton.tsx:139-164).
    3. React Native routes touches by the React tree, so the dropdown's contents still count as children of the empty-state ScrollView. That ScrollView uses the default keyboardShouldPersistTaps="never". With the keyboard up, a tap on anything that isn't a text input blurs the input and is consumed.
    4. The selection list sets keyboardShouldPersistTaps="always" only on its own list (BaseSelectionListWithSections.tsx:378). The search input renders outside that list (L349), so the clear button gets no protection.
    5. Only empty reports are affected, because reports with expenses use the unified list, which already sets "handled".

    Ruled out: no other PR in the current deploy checklist touched TextInput, the clear button, the base selection list, or the ScrollView wrapper.

    Not verified: this is a native-only bug, so it wasn't reproduced on web. Nothing in the cause is iOS-specific, so Android is probably affected too. Tapping a list option while the keyboard is open probably also takes two taps.

    Severity: on its own this is minor. A second tap or backspace works around it. It should stay a blocker because it shares a cause with the four blockers above.

    Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

    view run

  11. melvin-bot commented on Oct 13, 2026

    @melvin-bot
    melvin-botBot
    on Oct 13, 2026 – with 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.

  12. m-natarajan commented on Oct 13, 2026

    @m-natarajan
    m-natarajan
    on Oct 13, 2026

    Not repro, iPhone 17 Pro / 27.0.1

    103918-iOS.mp4
  13. melvin-bot
    added
    ReviewingHas a PR in review
    on Oct 13, 2026
  14. cristipaval
    removed
    DeployBlockerCashThis issue or pull request should block deployment
    on Oct 14, 2026
  15. cristipaval
    closed this as completedon Oct 14, 2026
  16. github-project-automation
    moved this to Done in #expensify-bugson Oct 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugSomething is broken. Auto assigns a BugZero manager.EngineeringHourlyKSv2ReviewingHas a PR in review

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions