[$500] Request money - Distance - Keyboard is showing for brief moment of time while coming from delete waypoint

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Click on FAB icon
2. Then select request money
3. Click on distance TAB
4. Click on add stop button
5. Click on stop which is added
6. Then select three dots (top most right)
7. And delete this waypoint

Expected Result:

Keyboard should not be show

Actual Result:

Keyboard is showing for brief moment of time

Workaround:

Unknown

Platforms:

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

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: v1.3.66-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

Notes/Photos/Videos: Any additional supporting documentation

RPReplay_Final1693940882.MP4

RPReplay_Final1694465713.MP4

Expensify/Expensify Issue URL:

Issue reported by: @niravkakadiya25

Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693941099472519

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~018ef807527bb44c5b
• Upwork Job ID: 1701342038677569536
• Last Price Increase: 2023-09-11
• Automatic offers:
• tienifr | Contributor | 26874632
• niravkakadiya25 | Reporter | 26874633

[melvin-bot]

Triggered auto assignment to @sonialiap (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]

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

[melvin-bot]

Current assignee @sonialiap is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[paultsimura]

Proposal

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

The keyboard is visible for a second while removing a stop.
Note: it's also visible after clicking "Delete stop" before opening the confirmation modal.

What is the root cause of that problem?

We have the textInput element focus set on the load here:

App/src/pages/iou/WaypointEditor.js

Line 163 in 89598d8

onEntryTransitionEnd={() => textInput.current && textInput.current.focus()}

It's gaining the focus back when the modal is closing, which opens the keyboard for input.

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

Call the textInput.current.blur() and textInput.current.focus() based on the conditions:

• When we open/close the "Delete Stop" confirmation modal (setting isDeleteStopModalOpen) – I would recommend creating separate functions showDeleteStopModal and hideDeleteStopModal, call blur/focus in them accordingly, and use them instead of calling setIsDeleteStopModalOpen(true/false);
• When we confirm removal of the stop – at deleteStopAndHideModal.

What alternative solutions did you explore? (Optional)

[hungvu193]

Proposal

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

Request money - Distance - Keyboard is showing for brief moment of time while coming from delete waypoint

What is the root cause of that problem?

In iOS once modal is closed, the keyboard will appear again before navigating to previous page which caused glitch only in iOS.

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

Add shouldEnableKeyboardAvoidingView={false} to our ScreenWrapper of WaypointEditor.
In deleteStopAndHideModal function, add Keyboard.dimiss() to hide the modal completely.

What alternative solutions did you explore? (Optional)

N/A

[tienifr]

Proposal

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

Keyboard is showing for brief moment of time:

• After deleting the stop (as in the OP)
• Between clicking Delete waypoint in the three dots menu and the stop deletion confirmation modal opens

What is the root cause of that problem?

It's the same issue as this one.

In iOS, when a modal is opened while the keyboard is still opened, the default behavior is that the keyboard will be closed, then after the modal is closed, the keyboard will reopen again.

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

We should use the same fix as that issue. When the three dot button is pressed, we should dismiss the keyboard.

We can add to here

onThreeDotsButtonPress={() => Keyboard.dismiss()}

According to this, only iOS refocuses after closing the modal, so we don't have to reopen the keyboard after the modal is dismissed, to be consistent with other platforms.

That's exactly the same approach taken in the other similar issue.

What alternative solutions did you explore? (Optional)

If we want to future-proof this for future usage of the three dots menu, we can put the Keyboard.dismiss logic in the ThreeDotsMenu or HeaderWithBackButton itself.

Instead of Keyboard.dismiss, calling blur on textInput is also fine.