Dev: Web - Magic code does not blur during sign in loading

[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!

---

Action Performed:

. Go to login page, enter email and click Continue
2. Type quickly more than 6 digits in the magic code field
3. Once 6th digit is entered, signing in starts.
4. Then the magic input should blur till backend returns success or error.
5. See that while signing in started, the 7th digit onwards can still be typed into magic input.

Expected Result:

Magic input should blur on entering 6th digit till backend sends its response

Actual Result:

Describe what actually happened

Workaround:

Magic input is not blurred

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: Dev 1.3.41-2
Reproducible in staging?: n/a
Reproducible in production?: n/a
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

Screen.Recording.2023-07-16.at.2.23.21.PM.mov

**Expensify/Expensify Issue U@c3024
Issue reported by: @c3024
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1689497435352449

View all open jobs on GitHub

[melvin-bot]

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

[ygshbht]

Proposal

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

The problem arises when a user types quickly in the magic code input field during the login process. As soon as the 6th digit is entered, the application begins the process of signing in. However, the magic code input field does not blur as expected and the user can still continue typing more digits beyond the 6th one. This should not be the case and the input field should become inactive until a response is received from the server.

What is the root cause of that problem?

This issue is caused by the absence of a robust mechanism in the application to disable the magic code input field during the sign-in loading process. The logic to blur (disable) the magic code input field once 6 digits have been entered and the sign-in process has started is not effectively implemented or might be missing entirely.

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

A reliable solution to fix this issue is to pass an isLoading prop to the MagicCodeInput component. This prop can be used to set the disabled state of the TextInput component. When the isLoading prop is true, the TextInput component becomes disabled, preventing further input until a response is received from the server.

This prop can be passed from the BaseValidateCodeForm component like so:

<MagicCodeInput
    ...
    isLoading={props.account.isLoading}
    ...
/>

This solution works effectively to prevent further input once the signing in process starts. If there is existing logic that has been designed to address this scenario, but is not performing as expected, it is feasible to examine and correct it. By doing so, we can preserve the consistency and coherence of the codebase. Any adjustment or refactoring needed can be accomplished without introducing any disruptions, ensuring the feature's functionality aligns seamlessly with the rest of the application's behavior.

2x.mp4

[c3024]

Reproducible during staging as well.

[aimane-chnaif]

This is fixed in #23023

[trjExpensify]

Ah cool, thanks for that!

This is a dupe of #21293 & #23087. Closing!

[c3024]

#23087 was opened later. This was opened before #23087.

[c3024]

@trjExpensify this is opened first before #23087. This should get the bug reporting bounty.

[trjExpensify]

Ah cool, fair. @garrettmknight want to pay out on the job linked to the issue that's open?