[$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 contributors@expensify.com 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): luongquocvu92@gmail.com
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-14

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.