[$500] Re-entering same wrong magic code and verify keeps last digit in green

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open the app
2. Open settings ->profile-> contact method->add any contact method
3. Open that newly added contact method and enter wrong code
4. Dismiss the error and again add same wrong code over it
5. Click verify and observe that last digit still has green dash

Expected Result:

App should have red dash below all the digits when error is triggered in add contact method

Actual Result:

App displays last digit with green dash when error is dismissed and again same code is entered and error is triggered in add contact method

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: 1.3.63-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
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

green.dash.on.last.digit.on.re.enter.same.code.mp4

Recording.421.mp4

Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693501161646589

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013d5900e7078ce653
• Upwork Job ID: 1699715481614094336
• Last Price Increase: 2023-09-28

[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

[m-natarajan]

Proposal by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693501161646589

Proposal

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

We are solving the problem of app displaying green border to magic code first and last field when submitted without any value or when resubmitted same value

What is the root cause of that problem?

Currently in MagicCodeInput component, there is not way to find out whether verify button was triggered or not due to which focusedIndex value is not changed whenever we trigger verify. This lack of data is causing green background for first or last digit even on error in multiple different scenario's like:

1. verify button click when there is no input
2. verify button click when we re-enter same invalid code

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

We have to introduce variable which will let us know that verify button was triggered and introduce new condition to display borderColorFocus. This will help us to not only solve the issue for current scenarios but also fullproof the solution for any other such scenarios.
In BaseValidateCodeForm page of settings->profile->Contacts:
We can add verifyCode state at following location

const [verifyClick,setVerifyClick]= useState(false);

Set the state to true on verify button click at following location

setVerifyClick(true);

Pass on both the variable and method (so we can again it to false on focus of any input) at following location

verifyClick={verifyClick}
verifyClickChange={setVerifyClick}

In MagicCodeInput component:
Set default prop values to avoid issues with component used at different location (tested at all other locations to see if its working fine or not) by adding the code [here] (

App/src/components/MagicCodeInput.js

Line 62 in 9701fbe

hasError: false,

):

verifyClick: false,
verifyClickChange: ()=>{},

Modify style condition for the digit view to allow borderColorFocus only if value is false by changing code here

focusedIndex === index && !props.verifyClick ? styles.borderColorFocus : {},

Set verifyClick value to false in onFocus to ensure it only affects once after verify button click and does not hinder normal border color change by adding code here

props.verifyClickChange(false)

This will also modify state value in BaseValidateCodeForm of settings->profile->Contacts.

What alternative solutions did you explore? (Optional)

[alitoshmatov]

Dupe - #20416

[conorpendergrast]

@alitoshmatov Can you add some context? Same root cause, but different effect?

[bernhardoj]

I think it's not a dupe. In this issue, the validation request does not run at all when the magic code value is the same.

[alitoshmatov]

@bernhardoj You right, I think I made mistake. It does not look same
cc: @conorpendergrast

[conorpendergrast]

Nice, thanks for the confirmation there! I'll review and triage this accordingly

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~013d5900e7078ce653

[melvin-bot]

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

[melvin-bot]

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

[conorpendergrast]

Reproduced!

[neonbhai]

Proposal

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

Re-entering same wrong magic code and verify keeps last digit in green

What is the root cause of that problem?

We do not blur the MagicCodeInput component when we submit the code using the button here:

App/src/pages/settings/Profile/Contacts/ValidateCodeForm/BaseValidateCodeForm.js

Lines 199 to 202 in db1a306

	<Button
	isDisabled={props.network.isOffline}
	text={props.translate('common.verify')}
	onPress={validateAndSubmitForm}

The validateAndSubmitForm function here is missing blur logic:

App/src/pages/settings/Profile/Contacts/ValidateCodeForm/BaseValidateCodeForm.js

Lines 136 to 149 in db1a306

	const validateAndSubmitForm = useCallback(() => {
	if (!validateCode.trim()) {
	setFormError({validateCode: 'validateCodeForm.error.pleaseFillMagicCode'});
	return;
	}
	if (!ValidationUtils.isValidValidateCode(validateCode)) {
	setFormError({validateCode: 'validateCodeForm.error.incorrectMagicCode'});
	return;
	}
	setFormError({});
	User.validateSecondaryLogin(props.contactMethod, validateCode);
	}, [validateCode, props.contactMethod]);

The current behaviour degrades UX as goes against the general user expectation of blurring when a button is clicked.

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

We should add blur logic to the validateAndSubmitForm function here:

if (inputValidateCodeRef.current) {
    inputValidateCodeRef.current.blur();
}

The inputValidateCodeRef should also be added as useCallBack function dependency here.

This change is needed as when an action context is clicked, blur is expected.

Result

This works perfectly:

Screencast.from.08-09-23.08.48.52.PM.IST.webm

Clicking verify takes away the focus

What alternative solutions did you explore? (Optional)

xx

[dukenv0307]

Proposal

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

App displays last digit with green dash when error is dismissed and again same code is entered and error is triggered in add contact method

What is the root cause of that problem?

When we blur the magic code input by clicking outside (including clicking the Verify button`), the input will be blurred, but the "green" underline will still remain. Try clicking anywhere outside the Magic Code Input, we'll see the Magic Code Input looks like it's focused (is green) but when typing, it does not register any value.

In this case, although we click on a button outside, the input is validated (and show error), but the green underline remains.

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

We need to blur the magic code input properly if the TextInput item is blurred and it's the currently focused item.

We should add

onBlur={() => {
    if (index !== focusedIndex) {
        return;
    }

    blurMagicCodeInput();
}}

to below this line

That should already work fine, but we can improve the condition further by early return if the "related target" of the blur is another text input item (we don't need to blur the magic code input if we're clicking on another input item).

This will fix:

• This issue
• The issue when clicking outside the magic code input, the magic code input still looks focused but is unresponsive when typing numbers.

What alternative solutions did you explore? (Optional)

If instead we want the text input focus to be sticky (if clicking outside, it will not blur the input, and we can still type), then we need to use a combination of keyboardShouldPersistTaps and preventDefault (or listen to keyboard events to listen to the key pressed). I can explain more if this is the direction we want to go.

[melvin-bot]

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

[melvin-bot]

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

[cead22]

Can somebody summarize what the different proposals do at a high level, and what the behavior is

• When you're entering numbers and click/tap outside the inputs
• When you're entering less than 6 numbers, and click verify (do the inputs stay highlighted, can you still enter numbers?)

Maybe it's worth discussing in #expensify-open-source what the ideal behavior should be, cause I think clicking/tapping outside the inputs should remove the focus (and highlight) from them, but I also think it'd be good, at least for the login page, to re-focus on the last input when an invalid magic code is entered and we put an error message on the screen

[melvin-bot]

@cead22 @ArekChr @laurenreidexpensify this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[neonbhai]

Hi @cead22,
Summarizing proposals here:

---

1. neonbhai's proposal(comment):

Root Cause:

Stating that the verify button on the add contact method does not take away the blur (it is missing the code for it). Whereas Verify buttons in similar flows do take away the blur.

Proposed Fix:

Add blurring logic on Verify

---

2. dukenv's proposal(comment):

Root Cause:

Stating that blur on clicking outside is missing from the core MagicCodeInput.js component. We are not handling blur on the component itself.

Proposed Fix:

Add onBlur prop to all the six textInput areas that will take away their focus when clicked outside.

[neonbhai]

Just stating that dukenv's problem has already been reported here and issue is being worked on.

We are still missing the Focus Check on the Verify button click in AddContactMethod flow.

[cead22]

@ArekChr sounds like we're leaning towards using @neonbhai 's proposal, can you confirm before I assign? Thanks

[dukenv0307]

Just stating that dukenv's problem has already been reported #18244 and issue is being worked on.

@neonbhai thanks for the link! Looks like that one was merged and this GH issue is no longer reproducible in latest main though.

cc @cead22

[melvin-bot]

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

[melvin-bot]

@cead22, @ArekChr, @laurenreidexpensify Huh... This is 4 days overdue. Who can take care of this?

[laurenreidexpensify]

@ArekChr bump thanks - #26813 (comment)

[ArekChr]

@ArekChr sounds like we're leaning towards using @neonbhai 's proposal, can you confirm before I assign? Thanks

Yes, agree

[melvin-bot]

@cead22 @ArekChr @laurenreidexpensify this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

Current assignee @ArekChr is eligible for the Internal assigner, not assigning anyone new.

[laurenreidexpensify]

@ArekChr do you agree that is no longer reproducible - #26813 (comment)?

[ArekChr]

@laurenreidexpensify The issue is still reproducible, the last input is still focused (green) when entering the same number and pressing verify.

Nagranie.z.ekranu.2023-10-5.o.16.09.15.mov

[dukenv0307]

I think we might want to hold on this PR, that fix might solve this one.

[Santhosh-Sellavel]

This was found earlier while our testing, will be handled here.
So lets hold this one, thanks!
cc: @cead22 @ArekChr

[Santhosh-Sellavel]

May be I miss understood the problem, but after second look I see the actual issue described no longer reproducible on staging, Its already addressed. Only problem is last item still green on error case and that is addressed on our refactor PR.

cc: @cead22 @ArekChr

[cead22]

Sounds like we can close, but reopen if I misunderstood

[dhanashree-sawant]

Hi @cead22, @Santhosh-Sellavel the actual issue is itself the green last digit which is still reproducible. If it is being handled by that PR, would this be eligible for reporting bonus as PR is raised for issues raised after this issue.

[cead22]

I don't think so, since that PR links to 3 other issues, so this is just another symptom of the same root cause