[$250] Android - Chat - When context menu is closed, keyboard doesn´t open again

[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: 9.0.60-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5204110&group_by=cases:section_id&group_order=asc&group_id=292106
Issue reported by: Applause Internal Team

Action Performed:

1. Open the Expensify app.
2. Open any chat.
3. Tap on compose box to open the keyboard.
4. Long tap on any message to open context menu.
5. Verify that keyboard is closed when context menu is opened.
6. Tap outside of the context menu to close it.
7. Verify that keyboard is opened again.

Expected Result:

When the context menu is closed, keyboard should be displayed again.

Actual Result:

After the context menu is closed, keyboard is not opened again, despite compose box being focused.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6662106_1731387510202.Context.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021856600731292480706
• Upwork Job ID: 1856600731292480706
• Last Price Increase: 2024-11-27

Issue Owner

Current Issue Owner: @Christinadobrzyn

[melvin-bot]

Triggered auto assignment to @Christinadobrzyn (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/~021856600731292480706

[melvin-bot]

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

[Christinadobrzyn]

Oh this is a good one - I think this can be external since it's affecting multiple platforms.

[Pholenk]

Edited by proposal-police: This proposal was edited at 2024-11-15 11:50:54 UTC.

Proposal

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

Android - Chat - When context menu is closed, keyboard doesn´t open again

What is the root cause of that problem?

The keyboard is dismissed because the popup menu's appearance does not cause the input to lose focus; when the popup menu disappears, the input is still focused.

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

• We need to add these lines to track whether the input is focused and popup menu is active at

  App/src/pages/home/report/ReportActionItem.tsx

  Line 190 in 9228354

const [isMenuActive, setIsMenuActive] = useState(false);
const isPrevMenuActive = usePrevious(isMenuActive);
const [isReportInputFocused, setIsReportInputFocused] = useState(false);
const keyboardState = useKeyboardState();

• To track that input has been focused once, add this useEffect at

  App/src/pages/home/report/ReportActionItem.tsx

  Line 272 in 9228354

useEffect(() => {
        if (!keyboardState.isKeyboardShown) {
            return;
        }
        setIsReportInputFocused(true);
}, [keyboardState.isKeyboardShown]);

• Add this useEffect to track whether pop up menu is shown

useEffect(() => {
        setIsMenuActive(isContextMenuActive || !!(isEmojiPickerActive ?? isPaymentMethodPopoverActive));
}, [isContextMenuActive, isEmojiPickerActive, isPaymentMethodPopoverActive]);

• After all, add this useEffect to execute the logic

useEffect(() => {
        if (!isPrevMenuActive && isMenuActive) {
            ReportActionComposeFocusManager.composerRef.current?.blur();
        }

        if (isPrevMenuActive && !isMenuActive && isReportInputFocused) {
            ReportActionComposeFocusManager.composerRef.current?.focus();
            setIsReportInputFocused(ReportActionComposeFocusManager.composerRef.current?.isFocused() ?? true);
        }
}, [isMenuActive, isPrevMenuActive, isReportInputFocused]);

What alternative solutions did you explore? (Optional)

Result

screencast-Genymotion-2024-11-14_02.29.56.567.mp4

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.

[Christinadobrzyn]

hi @jjcoffee can you check on the above proposal when you have a moment? TY!

[jjcoffee]

@Pholenk Thanks for your proposal! Your RCA is plausible, but I'm missing a bit more detail on why this only occurs on Android native.

For your solution, it would also be helpful for you to add where you propose to make your changes, ideally by linking to a relevant code snippet.

[Pholenk]

Proposal

Updated

[Pholenk]

@Pholenk Thanks for your proposal! Your RCA is plausible, but I'm missing a bit more detail on why this only occurs on Android native.

For your solution, it would also be helpful for you to add where you propose to make your changes, ideally by linking to a relevant code snippet.

I have checked that this issue behaves the same way as when the user presses the physical back button while the keyboard is open/shown and, based on react native official documentation, it is a known issue for Android.

[jjcoffee]

I actually can't reproduce on latest main, are you still able to reproduce @Pholenk?

issue-52390-test-2024-11-15_14.25.11.mp4

@Christinadobrzyn Can we ask for a retest?

[Pholenk]

I am still able to reproduce after syncing my fork and using the fresh install version @jjcoffee
Here is the commit ID that I used 4964af5b1fbb0225a52f560c73dc9660769bae28

screencast-Genymotion-2024-11-15_22.52.48.168.mp4

[Christinadobrzyn]

@Christinadobrzyn Can we ask for a retest?

I tested again on Google Pixel 6 Pro 13.0 NewDot version 9.0.60-0. it looks like the keyboard is not opening on Step 7 (of the OP)

screenRecording-18-11-2024-10-3.mp4

[jjcoffee]

Hmm strange, I can't reproduce it at all (using Medium Phone API 34)! Are there any steps I might be missing? Have you tried with a small(er) chat, e.g. with a brand new user?

@Pholenk I don't think I can accept the RCA in your proposal without it dealing with why the bug is not happening consistently.

[Pholenk]

Hmm strange, I can't reproduce it at all (using Medium Phone API 34)! Are there any steps I might be missing? Have you tried with a small(er) chat, e.g. with a brand new user?

@Pholenk I don't think I can accept the RCA in your proposal without it dealing with why the bug is not happening consistently.

If that's the case, have you tried with the lower API such as 33 or lower @jjcoffee?
I'm afraid it's not reproducible only for API 34 because I and Christina used the same API (API 33 for Android 13)

I tried with a newly created account, latest version of main branch, and this issue is still there.
https://github.com/user-attachments/assets/0a321075-d68b-47fd-a250-6cbf149f932c

[jjcoffee]

@Pholenk Ah yes, I can reproduce it now on API 33, thanks for the tip! Can you explain why that is?

[Pholenk]

You're most welcome @jjcoffee.

I have checked that this issue behaves the same way as when the user presses the physical back button while the keyboard is open/shown and, based on react native official documentation, it is a known issue for Android.

As far as I know, this happened because of this known issue of the text input focus.
That's why I propose to make the text input lose its focus programmatically before the context menu shows up and re-focus it again after the context menu disappears.

[melvin-bot]

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

[jjcoffee]

@kirillzyusko Any update on this?

[Christinadobrzyn]

Hi @kirillzyusko I'm going to add you to this GH for tracking - can you provide an update for us? TY!

[kirillzyusko]

@jjcoffee no, not yet, sorry. I was busy (and I'm still busy) with resolving some urgent deploy blockers 😔 Hopefully we can squash all of them soon and I'll get back to all issues that I was assigned to!

[melvin-bot]

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

[Christinadobrzyn]

Just checking in on this @kirillzyusko - if you have an update on the status of working on this that'd be great! TY!

[melvin-bot]

@kirillzyusko @jjcoffee @Christinadobrzyn this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

@kirillzyusko, @jjcoffee, @Christinadobrzyn Whoops! This issue is 2 days overdue. Let's get this updated quick!

[jjcoffee]

Not overdue - just waiting for @kirillzyusko to get a chance to look into this 🙏

[kirillzyusko]

Looking into it right now 👀

[kirillzyusko]

Okay, the problem is present in Android itself.

iOS and Android have a different behavior in terms of restoring keyboard state after Modal dismissal: iOS will show a keyboard again, but Android may not show keyboard again (depends on Android version, Android 14-15 shows the keyboard again when Modal gets hidden, Android 13 doesn't do that by default).

The solution would be to force show a keyboard on Android to match the iOS behavior, however:

• we can't simply call ref.focus() because as @Pholenk pointed out it's a known bug in RN (focus will not bring keyboard back);
• the solution proposed by @Pholenk includes blurring input when context menu gets shown and then requesting a focus when menu gets hidden. While it works I have a feeling that we add more complexity because for force showing a keyboard we have to remember about blurring the keyboard and restoring a focus - this is the additional code that we need to maintain;
• I think a slightly better solution would be to have something like this:

const shouldRestoreFocus = useRef(false);

useEffect(() => {
    if (isVisible) {
        shouldRestoreFocus.current = Keyboard.isVisible();
    }

    if (!isVisible && shouldRestoreFocus.current) {
        InteractionManager.runAfterInteractions(() => {
            KeyboardController.setFocusTo("current");
        });
    }
}, [isVisible]);

I put this code into BaseReportActionContextMenu.tsx, but I think it can be moved into a separate re-usable hook (useFocusRestoreEffect for example).

The key difference in the code that I propose is that:

• we don't need to use transitive refs (such as ReportActionComposeFocusManager.composerRef.current) - setFocusTo("current") will automatically restore a focus to last focused field;
• setFocusTo("current") doesn't have a limitation which is present in react-native (you still can set focus and keyboard will be shown).

@jjcoffee curious to know your thoughts 🙌

[jjcoffee]

@kirillzyusko That sounds like a good, clean solution to me - I also like the idea of moving it into a reusable hook. Let's do it!

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[aldo-expensify]

PR merged