[$250] Hybrid - Android -Chat - Keyboard blocks composer after leaving it open and selecting another user for DM

[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: v9.0.84-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: No, reproducible on hybrid only
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Pixel 7 Pro /Android 15
App Component: Other

Action Performed:

Precondition: have something typed (but not sent) to someone else in ND

1. Open the Android Hybrid app
2. Select any user to DM
3. Enter some texts on the composer and send it
4. Tap on the search button
5. Select another user to DM from the recent list (with the precondition fulfilled)
6. See that the keyboard now blocks composer

Expected Result:

The keyboard should not block the composer and should focus on the composer to allow text entry.

Actual Result:

The keyboard blocks the composer after entering text, leaving the keyboard open, and selecting another user to DM from the recent list

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6712789_1736740810015.Block.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021878988628495834641
• Upwork Job ID: 1878988628495834641
• Last Price Increase: 2025-01-28
• Automatic offers:
• daledah | Contributor | 105911098

Issue Owner

Current Issue Owner: @getusha

[melvin-bot]

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

[kadiealexander]

iOS <> Android bug swap.

[jliexpensify]

@IuliiaHerets the steps are incomplete, they should be:

Precondition: have something typed (but not sent) to someone else in ND

1. Open the Android Hybrid app
2. Select any user to DM
3. Enter some texts on the composer and send it
4. Tap on the search button
5. Select another user to DM from the recent list (with the precondition fulfilled)
6. See that the keyboard now blocks composer

[melvin-bot]

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

[melvin-bot]

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

[daledah]

Proposal

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

Hybrid - Android -Chat - Keyboard blocks composer after leaving it open and selecting another user for DM

What is the root cause of that problem?

After step 5, the search modal is closed first:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Line 247 in 7b8bb55

onRouterClose();

At this point, the keyboard will reopen if it was already active before step 4. Then, it navigates to another report:

App/src/components/Search/SearchRouter/SearchRouter.tsx

Lines 249 to 253 in 7b8bb55

	if (item?.reportID) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));
	} else if ('login' in item) {
	ReportUserActions.navigateToAndOpenReport(item.login ? [item.login] : [], false);
	}

Here, since the keyboard remains visible from the previous report screen, it continues to be displayed on the new screen. And because the condition to use the keyboard avoiding view:

App/src/pages/home/ReportScreen.tsx

Line 760 in 7b8bb55

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

is false, leads to the bug "Keyboard blocks composer after leaving it open and selecting another user for DM"

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

Keyboard should not be opened when navigating to a new report until we click on the composer. So, we can update this one:

                KeyboardUtils.dismiss().then(() => {
                    if (item?.reportID) {
                        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(item?.reportID));
                    } else if ('login' in item) {
                        ReportUserActions.navigateToAndOpenReport(item.login ? [item.login] : [], false);
                    }
                });

It can make sure the keyboard is closed successfully before navigating to new report.

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

What alternative solutions did you explore? (Optional)

[huult]

Proposal

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

Keyboard overlaps the composer when starting a new thread with keyboard open

What is the root cause of that problem?

This issue occurs because shouldEnableKeyboardAvoidingView is disabled.

App/src/pages/home/ReportScreen.tsx

Line 750 in ee611e6

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

shouldEnableKeyboardAvoidingView is disabled when isTopMostReportId is false or showSoftInputOnFocus is false.

Here is the log:

• 
• 

#55136 is related this issue

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

To fix this issue in all cases, I think shouldEnableKeyboardAvoidingView should always be enabled when the keyboard is open. To implement this, something like:

import keyboardHeight

  const {keyboardHeight} = useKeyboardState();

App/src/pages/home/ReportScreen.tsx

Line 750 in ee611e6

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

Update condition to enable shouldEnableKeyboardAvoidingView to:

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

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

This is a UI bug; no UI test is needed.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

@jliexpensify, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[jliexpensify]

Bumping @getusha for reviews please!

[melvin-bot]

@jliexpensify, @getusha 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[jliexpensify]

Bumping @getusha again for reviews please.

[melvin-bot]

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

[getusha]

Reviewing, will update soon!

[getusha]

@jliexpensify a QQ about the expected result, do we want to show the keyboard after returning to the DM from search page?
We fixed similar issue here #54968 by just hiding the keyboard but this seems slightly different.

[daledah]

@jliexpensify @getusha We've introduced a new expected behavior in this issue:

Always focus on the input field, but prevent the keyboard from opening on mobile and mWeb.

In other words:

When a report is opened for the first time, the input field should be focused, but the keyboard should remain closed automatically.

In the context of this bug—specifically step 5, 'Select another user to DM from the recent list (with the precondition fulfilled)'—a new report opens, the expected outcome should remain the same: the input field is focused, but the keyboard does not open.

[melvin-bot]

@jliexpensify @getusha 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]

@jliexpensify, @getusha Whoops! This issue is 2 days overdue. Let's get this updated quick!

[jliexpensify]

Bumping @getusha

[melvin-bot]

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

[getusha]

@daledah's proposal looks good to me. Seems like the expected result is to not show the on screen keyboard according to #55159 (comment)

🎀 👀 🎀 C+ Reviewed!

[melvin-bot]

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

[melvin-bot]

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