[Due for payment 2025-02-19] [$250] Android - Threads - Keyboard overlaps the composer when starting a new thread with keyboard open

[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.84-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5444620
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Android 14
App Component: Chat Report View

Action Performed:

1. Go to any chat and start a thread
2. Go to the thread message and tap and hold on it with the keyboard enabled on screen
3. Select Reply in a thread

Expected Result:

The thread starts with focus on the field and keyboard not blocking it

Actual Result:

When it's a new thread from a not threaded message, the keyboard doesn't appear and won't open instantly. When it's a subthread the keyboard overlaps the thread when starting a new thread

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6712202_1736648872338.az_recorder_20250112_042058.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021879497179353237600
• Upwork Job ID: 1879497179353237600
• Last Price Increase: 2025-01-29
• Automatic offers:
• allgandalf | Reviewer | 105976470
• truph01 | Contributor | 105976471

Issue Owner

Current Issue Owner: @sonialiap

[melvin-bot]

Triggered auto assignment to @sonialiap (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]

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

[melvin-bot]

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

[truph01]

Proposal

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

• When it's a new thread from a not-threaded message, the keyboard doesn't appear and won't open instantly. When it's a subthread the keyboard overlaps the thread when starting a new thread.

What is the root cause of that problem?

• Expected Behavior: When navigating to a new report screen, the composer should be focused, but the keyboard should not appear unless the user manually taps on the composer.

• Issue: The current behavior deviates from this expectation. Specifically, when the user clicks "Reply in thread," the keyboard appears even though the user has not interacted with the composer. Additionally, the condition for using the keyboard-avoiding view is false:
  

  App/src/pages/home/ReportScreen.tsx

  Line 750 in 018df99

  shouldEnableKeyboardAvoidingView={(isTopMostReportId || isInNarrowPaneModal) && (!isComposerFocus || showSoftInputOnFocus)}

  
  As a result, the keyboard overlaps the composer.

• Why "when the user clicks on "Reply in thread", the keyboard is shown"? The issue arises because the keyboard remains open when transitioning between reports. For instance, if the keyboard is visible in the parent report, and the user clicks "Reply in thread" to open the thread report, the keyboard is not properly dismissed before navigating. Consequently, it remains visible in the new thread report.

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

• We should dismiss the keyboard before navigating to thread report. So update:
  

  App/src/pages/home/report/ContextMenu/ContextMenuActions.tsx

  Line 268 in abe6868

  navigateToAndOpenChildReport(reportAction?.childReportID, reportAction, originalReportID);

                    KeyboardUtils.dismiss().then(() => {
                        navigateToAndOpenChildReport(reportAction?.childReportID, reportAction, originalReportID);
                    });

• We can also remove:

App/src/pages/home/report/ContextMenu/ContextMenuActions.tsx

Line 266 in abe6868

ReportActionComposeFocusManager.focus(true);

since the condition to update shouldAutoFocus is:

App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.tsx

Line 269 in abe6868

const shouldAutoFocus = !modal?.isVisible && shouldShowComposeInput && Modal.areAllModalsHidden() && isFocused && !didHideComposerInput;

It is optional.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

[melvin-bot]

@sonialiap, @allgandalf Huh... This is 4 days overdue. Who can take care of this?

[allgandalf]

looking...

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@sonialiap @allgandalf this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@sonialiap, @allgandalf Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

@sonialiap, @allgandalf Still overdue 6 days?! Let's take care of this!

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@sonialiap, @allgandalf 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[allgandalf]

I agree with the RCA and solution from @truph01 , lets go with their solution

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

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

Offer link
Upwork job

[melvin-bot]

📣 @truph01 🎉 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 📖

[truph01]

@allgandalf PR is ready.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

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

• fix: Keyboard overlaps the composer when starting a new thread #56304

If no regressions arise, payment will be issued on 2025-02-19. 🎊

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

• @allgandalf requires payment automatic offer (Reviewer)
• @truph01 requires payment automatic offer (Contributor)

[melvin-bot]

@allgandalf @sonialiap @allgandalf 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]