[$500] Android - IOU-From BNP page, tap next and navigate back, phone keypad opens

[izarutskaya]

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: 1.3.92-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. Launch app
2. Tap fab
3. Tap request money
4. Enter an amount
5. Tap next
6. Tap app's back button

Expected Result:

When user taps app's back button, phone keypad must not open.

Actual Result:

When user taps app's back button, phone keypad opens.

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

Android: Native

Bug6253269_1698410326558._eypad.mp4

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01c70a484f8520ecd4
• Upwork Job ID: 1717893710590554112
• Last Price Increase: 2024-01-02

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @conorpendergrast (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 - @s77rt (External)

[manlaig]

Proposal

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

Keyboard is focused on Android when navigating back to screen.

What is the root cause of that problem?

When disableKeyboard prop is enabled on TextInput, an AppState listener dismisses the keyboard on background or inactive events. It doesn't dismiss the keyboard on active event.

App/src/components/TextInput/index.native.js

Lines 9 to 19 in 22678a5

	if (!props.disableKeyboard) {
	return;
	}
	const appStateSubscription = AppState.addEventListener('change', (nextAppState) => {
	if (!nextAppState.match(/inactive|background/)) {
	return;
	}
	Keyboard.dismiss();
	});

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

Remove the conditional check inside the event callback that prevents dismissing the keyboard on active event. So, the listener would dismiss the keyboard on all AppState event changes and also initially dismiss the keyboard.
The code would look like:

    if (!props.disableKeyboard) {
        return;
    }
    Keyboard.dismiss();

    const appStateSubscription = AppState.addEventListener('change', (nextAppState) => {
        Keyboard.dismiss();
    });

What alternative solutions did you explore? (Optional)

Since we don't need the keyboard when disableKeyboard is set, removing the conditional check simplifies the code and initially calling dismiss prevents bugs like this. I think this is a general solution that will address similar keyboard bugs in the future.

[wlegolas]

Proposal

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

Android - IOU-From BNP page, tap next and navigate back, phone keypad opens

What is the root cause of that problem?

The problem is related to how quickly the user clicks on the back button or the slowness of the application when the user switches from the Participants view to go back to the Request Money page.

When the user clicks on the "Next" button to select the Participants we can see this behavior when:

• The Participants screen takes time to load and the user clicks on the back button
• Or when the user clicks quickly on the back button until the participant view is showing

As the text field in the Participant view receives the focus, the keyboard will be shown because it's an expected behavior for native devices, but this time the navigation is changing to the Request Money Page, this is the reason to see the keyboard open.

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

We need to change the Native input to add the logic to subscribe to the blur event from the Navigation and when the blur event occurs we need to call Keyboard.dismiss() to close the keyboard and change its state to close.

For example:

const TextInput = forwardRef((props, ref) => {
    const navigation = useNavigation();

    useEffect(() => {
        const unsubscribe = navigation.addListener('blur', () => {
            Keyboard.dismiss();
        });

        return unsubscribe;
    }, [navigation]);

    ...
});

What alternative solutions did you explore? (Optional)

N/A

POC

poc-issue-30511.mov

[s77rt]

Is there any specific requirements to reproduce this bug? Works fine from my end

Screen.Recording.2023-10-28.at.10.31.57.AM.mov

[conorpendergrast]

I can't reproduce via Browserstack either, I get the regular in-app keyboard:

[conorpendergrast]

@izarutskaya could you confirm if there's any extra information needed for reproduction? Is this specific to one particular Android device?

[s77rt]

Not overdue. Still requires bug reproduction confirmation

[melvin-bot]

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

[izarutskaya]

@conorpendergrast I can't reproduce this anymore. Build - 1.3.95-2

Screen.Recording.20231104.135822.New.Expensify.mp4

[s77rt]

I think we can close this @conorpendergrast

[conorpendergrast]

I agree, based on none of us being able to reproduce any more. Thanks for raising this @izarutskaya !

[lanitochka17]

Issue reproducible on latest build 1.4.1-5

Issue found when executing PR #30873

ul.mp4

[melvin-bot]

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

[s77rt]

Not overdue. Still not sure how to proceed though, it's either we fix this at Android or close the issue since we can't do much about it (/App perspective)

[melvin-bot]

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

[s77rt]

Asking in Slack if this can be closed https://expensify.slack.com/archives/C01GTK53T8Q/p1703083456350169 (low priority)

[s77rt]

Not overdue. Waiting on Slack input

[melvin-bot]

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

[s77rt]

Same ^

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[s77rt]

Not overdue. Not expecting much in Slack thread this week. Will bump the thread next week

[melvin-bot]

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

[s77rt]

Same ^

[s77rt]

Bumped the slack thread

[conorpendergrast]

I've replied in Slack, sorry that took so long! Based on that, I'll close out. If any disagrees, add a comment!