[$500] Android - Create room - Inconsistent behavior of cursor after selecting workspace/visibility

[kbecciv]

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: 1.3.98.0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. Open the app
2. Tap the FAB > Start chat > Room
3. Enter the room name
4. Select the workspace and/or visibility

Expected Result:

The cursor is not shown, and the keyboard is hidden

Actual Result:

On Android and iOS, the cursor returns to the room name, and the field is highlighted, while on web and mweb, the cursor is not seen, and the keyboard is hidden on mweb. On iOS, the keyboard overlaps the "Create room" button. Also, the keyboard is hidden on Samsung s10+, while it appears on Pixel 6.

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6271875_1699653421342.Android_pixel6.mp4

View all open jobs on GitHub

Bug6271875_1699653421346.iOS.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01fbab8ee06aa1521a
• Upwork Job ID: 1723173111736639488
• Last Price Increase: 2024-06-15

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @sakluger (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[bernhardoj]

The workspace/visibility is a modal, so the focus will be restored once the modal is closed. I think we should hold this for #24452 (comment)

[tienifr]

The workspace/visibility is a modal, so the focus will be restored once the modal is closed. I think we should hold this for #24452 (comment)

That other issue is related to Composer only, and only there we have the "the focus will be restored once the modal is closed" behavior. Here we should dismiss the keyboard when modal opens like the Expected suggested, because when the user goes to workspace/visibility step, it's most likely they already completes entering the room name and there's no need to refocus on the room name input.

Proposal

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

On Android and iOS, the cursor returns to the room name, and the field is highlighted, while on web and mweb, the cursor is not seen, and the keyboard is hidden on mweb. Also, the keyboard is hidden on Samsung s10+, while it appears on Pixel 6.

On iOS, the keyboard overlaps the "Create room" button.

This part is out of scope and I believe we already have another ticket to remove that.

What is the root cause of that problem?

In iOS and some Android devices, if a modal is opened while a keyboard is open, the keyboard will be dismissed natively but will resurface after the modal is closed. It's native behavior. While for web/mWeb it doesn't have that behavior.

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

We need to proactively dismiss the keyboard before the modal opens. We can do that by making use of the willAlertModalBecomeVisible of the Modal, it will become true right before the modal open, we need to listen to the modal state and dismiss the keyboard if the willAlertModalBecomeVisible changes from false to true. Also we'll only listen to the modal state if the current screen is focused. We can put the logic in a common useDismissKeyboardOnModalOpen hook for reuse.

function useDismissKeyboardOnModalOpen() {
    const willAlertModalBecomeVisibleRef = useRef(false);
    const isFocused = useIsFocused();    

    useEffect(() => {
        if (!isFocused) {
            return;
        }
        const unsubscribeOnyxModal = onyxSubscribe({
            key: ONYXKEYS.MODAL,
            callback: (modalArg) => {
                if (_.isNull(modalArg) || typeof modalArg !== 'object') {
                    return;
                }

                if (!willAlertModalBecomeVisibleRef.current && modalArg.willAlertModalBecomeVisible) {
                    Keyboard.dismiss();
                }

                willAlertModalBecomeVisibleRef.current = modalArg.willAlertModalBecomeVisible;
            },
        });

        return () => unsubscribeOnyxModal && unsubscribeOnyxModal();
    }, [isFocused]);
}

We use onyxSubscribe to minimize unnecessary component rerendering if the screen is not focused, this is already used elsewhere in the app. 1 alternative is to connect to modal in Onyx in the component.

Then we can use the hook in the WorkspaceNewRoomPage and any other page that has the issue.

What alternative solutions did you explore? (Optional)

We can add Keyboard.dismiss individually on press of the Workspace/visibility, but above is a more global fix.

If instead we want to autofocus whenever the modal closes, we can implement similarly in the useAutoFocusInput hook. If the modal.isVisible changes from true to false, we'll autofocus the input.

[bernhardoj]

(image taken from #24452 (comment))

That other issue is related to Composer only,

AFAICT, it will be applied to all Modal.

and there's no need to refocus on the room name input.

They also plan to add shouldRestoreKeyboard prop to the modal and in this case, we pass it as false. So, it's better to hold this.