[$250] mWeb - Search - In search, scrolling the page doesn't close the keypad.

[jponikarchuk]

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.1.40-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: N/a
Email or phone of affected tester (no customers): Slottwo1 sivappa2@gmail.com
Issue reported by: Applause Internal Team
Device used: Redminote note 10s android 13 phone
App Component: Chat Report View

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Login account with more chats
3. Tap search
4. Scroll the page up and down

Expected Result:

In search, scrolling the page must close the keypad.

Actual Result:

In search, scrolling the page doesn't close the keypad.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021922351372001950494
• Upwork Job ID: 1922351372001950494
• Last Price Increase: 2025-05-13
• Automatic offers:
• truph01 | Contributor | 107372286

Issue Owner

Current Issue Owner: @Beamanator

[melvin-bot]

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

[linhvovan29546]

Proposal

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

mWeb - Search - In search, scrolling the page doesn't close the keypad.

What is the root cause of that problem?

We already have logic to dismiss the keyboard on scroll, which works as expected in other parts of the app.

App/src/components/SelectionList/index.tsx

Lines 60 to 66 in 9586baf

	const defaultOnScroll = () => {
	// Only dismiss the keyboard whenever the user scrolls the screen
	if (!isScreenTouched) {
	return;
	}
	Keyboard.dismiss();
	};

However, it doesn’t work in the search screen because the search input is rendered via the SearchAutocompleteInput component.

App/src/components/Search/SearchAutocompleteInput.tsx

Line 226 in 9586baf

type="markdown"

Looking deeper, this component uses a TextInput with the type markdown, which on the web renders as a div with contentEditable. As a result, calling Keyboard.dismiss() has no effect in this OP
https://github.com/Expensify/react-native-live-markdown/blob/main/src/MarkdownTextInput.web.tsx#L772-L775

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

I think we can fix this by manually blur the input instead of relying on Keyboard.dismiss(). Here's the approach:

• Introduce a new props dismissExternalKeyboard in the SelectionList component.
• In the defaultOnScroll handler, call dismissExternalKeyboard() to hide the keyboard.
  

  App/src/components/SelectionList/index.tsx

  Lines 60 to 66 in 9586baf

  	const defaultOnScroll = () => {
  	// Only dismiss the keyboard whenever the user scrolls the screen
  	if (!isScreenTouched) {
  	return;
  	}
  	Keyboard.dismiss();
  	};

    const defaultOnScroll = () => {
        // Only dismiss the keyboard whenever the user scrolls the screen
        if (!isScreenTouched) {
            return;
        }
        if(dismissExternalKeyboard){
            dismissExternalKeyboard();
            return
        }
        Keyboard.dismiss();
    };

• The dismissExternalKeyboard function would look like this:
  

  App/src/components/Search/SearchAutocompleteList.tsx

  Line 566 in 9586baf

const dismissExternalKeyboard = () => {
    textInputRef?.current?.blur();
}; 
...
            <SelectionList<OptionData | SearchQueryItem>
                dismissExternalKeyboard={dismissExternalKeyboard}
                ...

• To make this work, we need to pass textInputRef as a prop from SearchRouter to SearchAutocompleteList.
  

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

  Line 356 in 9586baf

  <SearchAutocompleteList

                        textInputRef={textInputRef}

Note: We should also check other components like SearchPageHeaderInput and apply the same solution

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

Since this is a keyboard interaction issue specific to web behavior, automated testing isn't necessary in this case.

What alternative solutions did you explore? (Optional)

[truph01]

Proposal

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

• When using search, scrolling the page does not dismiss the on-screen keyboard.

What is the root cause of that problem?

• The SelectionList component already includes logic to dismiss the keyboard on scroll:
  

  App/src/components/SelectionList/index.tsx

  Line 65 in 9586baf

  Keyboard.dismiss();

• This logic calls Keyboard.dismiss(), which, on the web platform, invokes:

var dismissKeyboard = () => {
  TextInputState.blurTextInput(TextInputState.currentlyFocusedField());
};

See: https://github.com/necolas/react-native-web/blob/master/packages/react-native-web/src/modules/dismissKeyboard/index.js

• On web, there are two types of input elements:

  1. <input />
  2. <div contenteditable="true" /> (used in our search input)

• For <input />, the keyboard dismissal works correctly because the currently focused node is tracked through:
  https://github.com/necolas/react-native-web/blob/922c134f2b7c428cc19daaeb3cac4b6a4c8ec6a3/packages/react-native-web/src/exports/TextInput/index.js#L285

TextInputState._currentlyFocusedNode = hostNode;

• However, for <div contenteditable="true" />, TextInputState.currentlyFocusedField() returns null because there is no logic to update TextInputState._currentlyFocusedNode in this case. This is the root cause of the bug.

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

To resolve this, we need to ensure that TextInputState._currentlyFocusedNode is also updated for <div contenteditable="true" /> elements. This requires two steps:

Step 1: Export TextInputState from react-native-web so it can be used externally.

Update this logic:
https://github.com/necolas/react-native-web/blob/922c134f2b7c428cc19daaeb3cac4b6a4c8ec6a3/packages/react-native-web/src/exports/NativeModules/index.js#L10-L15

From:

import UIManager from '../UIManager';

// NativeModules shim
const NativeModules = {
  UIManager
};

To:

import UIManager from '../UIManager';
import TextInputState from '../../modules/TextInputState';

// NativeModules shim
const NativeModules = {
  UIManager,
  TextInputState
};

Step 2: Update the TextInputState._currentlyFocusedNode when the contenteditable div receives focus.

Modify the logic here:
https://github.com/Expensify/react-native-live-markdown/blob/0a5c7736d876ad11762aa88c736c1c9b860eedc7/src/MarkdownTextInput.web.tsx#L552-L553

From:

const handleFocus = useCallback(event => {

To:

const handleFocus = useCallback(event => {
  NativeModules.TextInputState._currentlyFocusedNode = hostNode;

What alternative solutions did you explore? (Optional)

• After implementing Step 1, another option is to update TextInputState._currentlyFocusedNode directly within the Expensify app instead of react-native-live-markdown. For example, update:
  

  App/src/components/RNMarkdownTextInput.tsx

  Line 52 in 9ad4ccb

  <AnimatedMarkdownTextInput

To:

<AnimatedMarkdownTextInput
    onFocus={(e) => {
        props?.onFocus?.(e);
        NativeModules.TextInputState._currentlyFocusedNode = e.target;
    }}
/>

[melvin-bot]

@muttmuure Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot]

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

[melvin-bot]

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

[parasharrajat]

Interesting issue.

I see that solving this issue on the lib level is not that complex so I think we can solve it at react-native-live-markdown lib.

Instead of exposing the UiManager which can't be done being internal module, we can access the TextInputState via TextInput.State. Then we can overide the _currentlyFocusedNode via TextInput.State.focusTextInput in focus handler.

@truph01's proposal aligns more with this approach thus I prefer their solution.

🎀 👀 🎀 C+ reviewed

[melvin-bot]

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

[parasharrajat]

Feedback:

Looking deeper, this component uses a TextInput with the type markdown, which on the web renders as a div with contentEditable. As a result, calling Keyboard.dismiss() has no effect in this OP

@linhvovan29546 I see that you were on the point in your root cause but you didn't explain why calling Keyboard.dismiss() has no effect. Let's try to add those details to add more value to your proposals.

[Beamanator]

So @parasharrajat do you think we should hold on hiring for now?

[parasharrajat]

@Beamanator Here is my main decision #61521 (comment). We can proceed with implementation.

[parasharrajat]

@Beamanator Bump.

[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]

@parasharrajat PR is ready

[parasharrajat]

Let's wait for maintainer review.

[parasharrajat]

Upstream lib PR is in progress. Close to merge.

[melvin-bot]

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

[parasharrajat]

@truph01 First PR is done. Waiting for next one...

[truph01]

@parasharrajat PR is ready

[parasharrajat]

The version in app is updated in #62788 so we don't need #62811 now.

Let's track #62788 timeline for payment of this issue. Thanks.

cc: @muttmuure