[Due for payment 2025-05-22] [$250] Android - RHP Field - Keyboard is not displayed when navigating back from Help Panel

[jponikarchuk]

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.1.21-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to check, new feature
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: #59156
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: Samsung Galaxy A12 / Android 13
App Component: User Settings

Action Performed:

Precondition : Help Panel is enabled

1. Open Hybrid app
2. Go to Settings
3. Tap the status icon
4. Open Help Panel
5. Close Help Panel

Expected Result:

The input field is focused, and on-screen keyboard is displayed, similar to mWeb behavior

Actual Result:

The input field is focused, but on-screen keyboard is not displayed, different from mWeb behavior

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6784750_1743110346795.Dvnb8264_1_.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021909740534838936622
• Upwork Job ID: 1909740534838936622
• Last Price Increase: 2025-04-15

Issue Owner

Current Issue Owner: @johncschuster

[melvin-bot]

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

[samranahm]

Proposal

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

Keyboard is not displayed when navigating back from Help Panel

What is the root cause of that problem?

App/src/pages/settings/Profile/CustomStatus/StatusPage.tsx

Line 163 in 1c74508

const {inputCallbackRef, inputRef} = useAutoFocusInput();

not automatically update when navigating back from Help Panel

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

We should add the useEffect here

const {inputCallbackRef, inputRef} = useAutoFocusInput();
useEffect(() => {
  if (inputRef.current) {
      inputRef.current.focus();
  }
}, []);

to automatically update when the page reload

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

N/A

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.

[daledah]

🚨 Edited by proposal-police: This proposal was edited at 2025-04-01 05:37:58 UTC.

Proposal

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

• The input field is focused, but the on-screen keyboard is not displayed—this behavior differs from how it works in mobile web (mWeb).

What is the root cause of that problem?

• We already have logic in place to focus the input after closing the help panel:

App/src/hooks/useAutoFocusInput.ts

Lines 59 to 65 in 9ce4864

	useEffect(() => {
	if (!shouldHideSidePane) {
	return;
	}
	setIsScreenTransitionEnded(isSidePaneTransitionEnded);
	}, [isSidePaneTransitionEnded, shouldHideSidePane]);

In this bug, the input is indeed being focused, but the on-screen keyboard does not appear because the modal animation transition is still in progress when the focus is triggered.

• The isSidePaneTransitionEnded flag is set right after the side pane animation completes:

App/src/hooks/useSidePane.ts

Line 81 in 9ce4864

]).start(() => setIsSidePaneTransitionEnded(true));

This animation is intended to simulate the modal close animation, but the timing doesn’t match exactly. As a result, when we call setIsSidePaneTransitionEnded(true) here:

App/src/hooks/useSidePane.ts

Line 81 in 9ce4864

]).start(() => setIsSidePaneTransitionEnded(true));

the actual modal animation might still be running.

• That’s why we had to introduce an additional delay of 150ms before refocusing the composer after the help panel closes:

App/src/hooks/useSidePane.ts

Line 112 in 9ce4864

focusComposerWithDelay(ReportActionComposeFocusManager.composerRef.current, CONST.ANIMATED_TRANSITION + CONST.COMPOSER_FOCUS_DELAY)(true);

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

• To ensure consistent behavior, we should apply the same approach used for refocusing the composer after closing the modal. Specifically, we should add a 150ms delay before triggering focus in this line:

App/src/hooks/useAutoFocusInput.ts

Line 64 in 9ce4864

setIsScreenTransitionEnded(isSidePaneTransitionEnded);

    const prevShouldHideSidePane = usePrevious(shouldHideSidePane)
    useEffect(() => {
        if (!shouldHideSidePane || !prevShouldHideSidePane) {
            return;
        }

       setTimeout(()=>{
        setIsScreenTransitionEnded(isSidePaneTransitionEnded);
       }, 150)
    }, [isSidePaneTransitionEnded, shouldHideSidePane]);

• In the snippet above, we not only introduce the 150ms delay, but also add a check for !prevShouldHideSidePane. This ensures that the focus logic does not run immediately after clicking the back button in the help panel modal. At that point, isSidePaneTransitionEnded may briefly be true, which could incorrectly trigger a focus before the transition has fully completed.

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

N/A

What alternative solutions did you explore? (Optional)

[bernhardoj]

Proposal

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

The keyboard doesn't show after the sidepane modal closed.

What is the root cause of that problem?

The main root cause is that the focus is called too early before the modal is completely closed.

We have a logic here in useAutoFocusInput that supposed to refocus an input after the side pane transition is done.

App/src/hooks/useAutoFocusInput.ts

Lines 58 to 67 in f01c7de

	// Trigger focus when side pane transition ends
	const {isSidePaneTransitionEnded, shouldHideSidePane} = useSidePane();
	const prevShouldHideSidePane = usePrevious(shouldHideSidePane);
	useEffect(() => {
	if (!shouldHideSidePane || prevShouldHideSidePane) {
	return;
	}
	setIsScreenTransitionEnded(isSidePaneTransitionEnded);
	}, [isSidePaneTransitionEnded, shouldHideSidePane, prevShouldHideSidePane]);

We already call setIsSidePaneTransitionEnded(true) after the animation finishes, but that doesn't mean the modal is completely closed (btw the animation here is web only).

App/src/hooks/useSidePane.ts

Lines 68 to 83 in f01c7de

	useEffect(() => {
	setIsSidePaneTransitionEnded(false);
	Animated.parallel([
	Animated.timing(sidePaneOffset.current, {
	toValue: shouldApplySidePaneOffset ? variables.sideBarWidth : 0,
	duration: CONST.ANIMATED_TRANSITION,
	useNativeDriver: true,
	}),
	Animated.timing(sidePaneTranslateX.current, {
	toValue: shouldHideSidePane ? sidePaneWidth : 0,
	duration: CONST.ANIMATED_TRANSITION,
	useNativeDriver: true,
	}),
	]).start(() => setIsSidePaneTransitionEnded(true));
	}, [shouldHideSidePane, shouldApplySidePaneOffset, sidePaneWidth]);

But that's not the real problem. The problem is in this useEffect. shouldHideSidePane is the modal visibility state. If it becomes false, then the modal will start to close and we only want to refocus after the transition is ended, isSidePaneTransitionEnded is true.

App/src/hooks/useAutoFocusInput.ts

Lines 58 to 67 in f01c7de

	// Trigger focus when side pane transition ends
	const {isSidePaneTransitionEnded, shouldHideSidePane} = useSidePane();
	const prevShouldHideSidePane = usePrevious(shouldHideSidePane);
	useEffect(() => {
	if (!shouldHideSidePane || prevShouldHideSidePane) {
	return;
	}
	setIsScreenTransitionEnded(isSidePaneTransitionEnded);
	}, [isSidePaneTransitionEnded, shouldHideSidePane, prevShouldHideSidePane]);

However, isSidePaneTransitionEnded is always true. Why? isSidePaneTransitionEnded is just a state inside the hook. Each usage of the hook creates a new instance of isSidePaneTransitionEnded state. useSidePane is being used in several places, and each hook has its own isSidePaneTransitionEnded. So, when isSidePaneTransitionEnded changes on SidePane component, for example, it won't affect the useAutoFocusInput. So, what happens is that the refocus happens immediately as soon as shouldHideSidePane becomes true.

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

We can create a context that we put in AuthScreens to hold the isSidePaneTransitionEnded so it's shared between all auth components, but the focus still happens too early, which is why we have a ComposerFocusManager (it actually handles all input focus on a Modal). We can enable shouldEnableNewFocusManagement for the side pane, which handles the refocus correctly, but it only refocuses if the input is previously focused before the modal shows (and it doesn't work on the web).

So, for our case, we can use isReadyToFocus from ComposerFocusManager before refocus on useAutoFocusInput.

ComposerFocusManager.isReadyToFocus().then(() => setIsScreenTransitionEnded(isSidePaneTransitionEnded));

(No need to create a context, but lmk if we want one)

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

N/A

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@johncschuster @rayane-d 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]

@rayane-d Eep! 4 days overdue now. Issues have feelings too...

[rayane-d]

Will review soon

[melvin-bot]

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

[huult]

Proposal

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

Keyboard is not displayed when navigating back from Help Panel

What is the root cause of that problem?

We called input.focus() too early, before the Help panel page was dismissed, so the keyboard failed to appear. This issue has occurred frequently

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

We don't know exactly when the keyboard is ready to appear, so I suggest that we re-focus the input to trigger the keyboard. This solution will fix and cover cases related to the timing of auto-focusing the input to show the keyboard.

1 Create new state

App/src/hooks/useAutoFocusInput.ts

Line 25 in c4122fb

  const [hasRequestedRefocus, setHasRequestedRefocus] = useState(false);

2. Set hasRequestedRefocus to true when calling input.focus()

App/src/hooks/useAutoFocusInput.ts

Line 26 in c4122fb

useEffect(() => {

    useEffect(() => {
        if (!isScreenTransitionEnded || !isInputInitialized || !inputRef.current || splashScreenState !== CONST.BOOT_SPLASH_STATE.HIDDEN) {
            return;
        }
        const focusTaskHandle = InteractionManager.runAfterInteractions(() => {
            requestAnimationFrame(() => {
                if (inputRef.current && isMultiline) {
                    moveSelectionToEnd(inputRef.current);
                }

                inputRef.current?.focus();
                setIsScreenTransitionEnded(false);
                setHasRequestedRefocus(true); // add this
            });
        });

        return () => {
            focusTaskHandle.cancel();
        };
    }, [isMultiline, isScreenTransitionEnded, isInputInitialized, splashScreenState]);

3. Create a new hook to check if isScreenTransitionEnded is false, the keyboard height is still 0, and hasRequestedRefocus is true, then trigger a refocus.

App/src/hooks/useAutoFocusInput.ts

Line 42 in c4122fb

     const {keyboardHeight} = useKeyboardState();
    useEffect(() => {
        const shouldRefocus = !isScreenTransitionEnded && keyboardHeight === 0 && hasRequestedRefocus;

        if (!shouldRefocus) {
            return;
        }

        Keyboard.dismiss();
        InteractionManager.runAfterInteractions(() => {
            inputRef.current?.focus();
        });

        return () => {
            setHasRequestedRefocus(false);
        };
    }, [keyboardHeight, isScreenTransitionEnded, hasRequestedRefocus]);

Screen.Recording.2025-04-15.at.23.12.56.mov

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

None

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]

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

[rayane-d]

Thanks, everyone, for your proposals!

Below is a side‑by‑side comparison of each idea:

Proposal	Strengths	Limitations
@samranahm's proposal – add a plain useEffect to call focus()	• Simple	• Focus still fires during the close animation, so the keyboard often stays hidden
@daledah's proposal – add a 150 ms delay before declaring transition end	• Mirrors composer‑refocus workaround already used elsewhere	• Relies on a “magic” 150 ms constant—may break in some cases
@bernhardoj's proposal – wait for ComposerFocusManager.isReadyToFocus()	• Uses the centralized focus‑management logic that guarantees the modal is fully gone (no hard‑coded delays) • Consistent with other modal‑focus flows • Minimal code change	• Introduces a tiny dependency on ComposerFocusManager inside useAutoFocusInput (acceptable)
@huult's proposal – re‑focus if keyboard height stays 0 (polling loop)	• Handles any edge case where focus fires too early	Adds extra state & effects, runs a refocus loop, and the first premature focus can still flash briefly

@bernhardoj’s proposal looks good to me because it:

• Removes timing “magic numbers”.
• Re‑uses ComposerFocusManager already handling modal/animation races.
• Keeps the patch minimal.

🎀👀🎀 C+ reviewed

[bernhardoj]

PR is ready

cc: @rayane-d

[melvin-bot]

This issue has not been updated in over 15 days. @francoisl, @johncschuster, @bernhardoj, @rayane-d eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

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

• Focus after help side panel modal is fully closed #60612

If no regressions arise, payment will be issued on 2025-05-22. 🎊

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

• @bernhardoj requires payment through NewDot Manual Requests
• @rayane-d requires payment through NewDot Manual Requests

[melvin-bot]

@rayane-d @johncschuster @rayane-d 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]

[johncschuster]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other:

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment:

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[johncschuster]

Payment Summary (to be issued after regression window has passed)

Contributor: @bernhardoj owed $250 via NewDot
Contributor+: @rayane-d owed $250 via NewDot

[bernhardoj]

Requested in ND.

[rayane-d]

BugZero Checklist:

• [Contributor] Classify the bug:

Bug classification

Source of bug:

• 1a. Result of the original design (eg. a case wasn't considered)
• 1b. Mistake during implementation
• 1c. Backend bug
• 1z. Other: Edge case

Where bug was reported:

• 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• 2b. Reported on staging (eg. found during regression or PR testing)
• 2d. Reported on a PR
• 2z. Other:

Who reported the bug:

• 3a. Expensify user
• 3b. Expensify employee
• 3c. Contributor
• 3d. QA
• 3z. Other:

• [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: Initial implementation of the Side Pane #56490 (comment)

• [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: N/A

• [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

• [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

• N/A

Test:

1. Go to Settings
2. Press the status icon
3. Press the help icon
4. Close the help panel
5. Verify the status input is focused and (for Android, Android mWeb, iOS) keyboard shows

Do we agree 👍 or 👎

[melvin-bot]

Payment Summary

Upwork Job

• Reviewer: @bernhardoj owed $250 via NewDot
• Reviewer: @rayane-d owed $250 via NewDot

BugZero Checklist (@johncschuster)

• I have verified the correct assignees and roles are listed above and updated the necessary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1909740534838936622/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[JmillsExpensify]

$250 approved for @bernhardoj

[rayane-d]

Requested in ND

[garrettmknight]

$250 approved for @rayane-d