[HOLD for payment 2023-04-28] [$1000] App displays phone number in result for brief moment even for invalid numbers (Bad UX)

[kavimuru]

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. Open the app
2. Open search
3. Search for long invalid number eg: 11111111111111 (observe result while writing the 14th digit)

Expected Result:

App should display invalid phone number error and shouldn't display phone number in result

Actual Result:

App displays invalid phone number error but also displays phone number in result for 1-2 seconds before removing it

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.2.97-2
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

glitch.invalid.phone.number.search.mp4

Recording.176.mp4

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

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01bee86ec37b82125e
• Upwork Job ID: 1645455781589475328
• Last Price Increase: 2023-04-17

[MelvinBot]

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

[MelvinBot]

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

[MitchExpensify]

Whats odd is that there is an account tied to an "invalid" number that exists ("+11111111111111"), so I guess the question is if we should show the "Please enter a valid phone number.." message at all when an account that matches the search exists. Also, what valid phone number is 14 digits long? Seems weird to me

[MitchExpensify]

Either way, it seems we've defined anything over 14 digits as "invalid" and this behaviour is weird so should be fixed

[MelvinBot]

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

[MelvinBot]

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

[MelvinBot]

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

[MelvinBot]

Triggered auto assignment to @chiragsalian (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[PrashantMangukiya]

Proposal

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

App displays phone number in result for brief moment even for invalid numbers (Bad UX)

What is the root cause of that problem?

When user type something it will trigger this.onChangeText as shown below:

App/src/pages/SearchPage.js

Line 185 in 3abe7b2

onChangeText={this.onChangeText}

WithinonChangeText() at line 80 it will trigger this.debouncedUpdateOptions.

App/src/pages/SearchPage.js

Lines 79 to 81 in 3abe7b2

	onChangeText(searchValue = '') {
	this.setState({searchValue}, this.debouncedUpdateOptions);
	}

App/src/pages/SearchPage.js

Line 58 in 3abe7b2

this.debouncedUpdateOptions = _.debounce(this.updateOptions.bind(this), 75);

Debounce is eventually calling updateOptions() function as shown below:

App/src/pages/SearchPage.js

Lines 126 to 142 in 3abe7b2

	updateOptions() {
	const {
	recentReports,
	personalDetails,
	userToInvite,
	} = OptionsListUtils.getSearchOptions(
	this.props.reports,
	this.props.personalDetails,
	this.state.searchValue.trim(),
	this.props.betas,
	);
	this.setState({
	userToInvite,
	recentReports,
	personalDetails,
	});
	}

During every render header message and sections data generated via this code:

App/src/pages/SearchPage.js

Lines 166 to 171 in 3abe7b2

	const sections = this.getSections();
	const headerMessage = OptionsListUtils.getHeaderMessage(
	(this.state.recentReports.length + this.state.personalDetails.length) !== 0,
	Boolean(this.state.userToInvite),
	this.state.searchValue,
	);

So here it will trigger multiple render and due to that, it will show Phone number in result for a moment and disappear thereafter. This is the root cause of the problem.

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

Here we can see that within updateOptions() we are calling OptionsListUtils.getSearchOptions() function with parameter as this.props.reports, this.props.personalDetails, this.state.searchValue.trim(), and this.props.betas etc.

So here we are not calling any backend api to generate search result, but passing value from props and state to OptionsListUtils.getSearchOptions() function. So here no need for debounce as it trigger render.

So we can remove debounce as shown in code below.
It will solve the problem and make user experience better as shown in result.

    //this.debouncedUpdateOptions = _.debounce(this.updateOptions.bind(this), 75);   // *** Old Code    
    this.updateOptions = this.updateOptions.bind(this);    // *** Updated Code

    onChangeText(searchValue = '') {
        // this.setState({searchValue}, this.debouncedUpdateOptions);  // *** Old Code
        this.setState({searchValue}, this.updateOptions);      // *** Updated Code
    }

What alternative solutions did you explore? (Optional)

None

Results

17200-SearchUi.mov

[tienifr]

Proposal

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

App displays invalid phone number error but also displays phone number in result for 1-2 seconds before removing it

What is the root cause of that problem?

The root cause is here

App/src/pages/SearchPage.js

Line 58 in cdcb335

this.debouncedUpdateOptions = _.debounce(this.updateOptions.bind(this), 75);

where we're debouncing the updateOptions, so 75ms after the user enters the input, we'll update the result list.

Debouncing is a good thing to prevent exessive re-rendering and was added on purpose here #3669. The actual problem is that we're delaying out input validation with the debounce.

If we notice in the OP video it's clear that the header message Please enter a valid phone number without brackets or dashes. If you're outside the US please include your country code (e.g. +15005550006). is shown immediately for an incorrect input. That's because the validation logic in https://github.com/Expensify/App/blob/main/src/libs/OptionsListUtils.js#L794 is not contained in the debounce, while the validation of the option list is.

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

We need to make sure input validation-related logic is extracted out of the debounce so that invalid input is highlighted immediately.

The header message is already doing it correctly, so we should apply the same for the option list.

As soon as the user type, if the input is invalid email/invalid phone, we should reset the options list immediately. This can be done by creating a function to wrap the phone and email validation logic in

App/src/libs/OptionsListUtils.js

Line 610 in cdcb335

&& ((Str.isValidEmail(login) && !Str.isDomainEmail(login)) || Str.isValidPhone(login))

.

And in

App/src/pages/SearchPage.js

Line 94 in 5eccf99

onChangeText(searchValue = '') {

we use the above function to check if the input is invalid phone/email. If it is, we already know that the userToInvite will be null and can set it to null in the state without involving any debounce.

The overhead of the validation is minimal and will provide the UX improvement needed for this error validation case.

What alternative solutions did you explore? (Optional)

NA

[hellohublot]

Proposal

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

App displays phone number in result for brief moment even for invalid numbers (Bad UX)

What is the root cause of that problem?

We update searchValue in onChangeText, and we also modify headerMessage in render at the same time, but our [recentReports, personalDetails, userToInvite] are modified after debounce, so the data is inconsistent

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

We can also modify headerMessage in debounce to ensure data consistency, so we add a new state.headerMessage, and then we update state.headerMessage in updateOptions

What alternative solutions did you explore? (Optional)

Not Yet

[fedirjh]

@PrashantMangukiya Thanks for the proposal. Debouncing was added to prevent unnecessary re-renders . Removing it will cause regressions , Please check this PR #3824 for more details.

[fedirjh]

@tienifr Thanks for the proposal. Your proposal will add unnecessary overhead , It may affect performance as it validate inputs in real time, and it will validate input twice.

[fedirjh]

@hellohublot, thank you for submitting the proposal. While I find your solution to be reasonable, I do not think your RCA appears to be correct. Instead of fixing the root cause, I believe it only hides the bug. My question is, why is the data inconsistent? As far as I know, getHeaderMessage relies on the actual state, so the error message should not be displayed until after the state is updated (following the debounce).

[tienifr]

@tienifr Thanks for the proposal. Your proposal will add unnecessary overhead , It may affect performance as it validate inputs in real time, and it will validate input twice.

@fedirjh we can extract the validation and reuse it between the getHeaderMessage and the onChangeText. So there'll be no overhead and no double input validation since the validation is already used in the getHeaderMessage and we only extract it to use in another place.

[fedirjh]

we can extract the validation and reuse it between the getHeaderMessage and the onChangeText.

@tienifr getHeaderMessage is used in multiples places across the App , your proposal will require extra changes and it will break DRY rules , beside that it doesn’t fix the root cause.

[hellohublot]

@fedirjh

Thanks for your suggestion

What I mean is that our headerMessage should be consistent with the sections.

I printed the sections and headerMessage in the SearchPage.render method. When we input 11111111111111, it printed sections=[{111111111111111}], headersMessage='please Enter Valid...' .

But the value of headersMessage is obviously incorrect, the headersMessage should match the sections, it should be ''

So my proposal is to suggest that we update headerMessage at the same time in updateOptions

[arayiksuqiasyan]

Proposal

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

App displays phone number in result for brief moment even for invalid numbers (Bad UX)

What is the root cause of that problem?

The main reason is getting sections when we don't need them, because we shouldn't show sections when we have a validation message

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

const sections = headerMessage ? [] : this.getSections();

we can pass an empty array of sections options when the header message property exists (meaning that if we have a validation message we shouldn't show sections), and when we pass sections of an empty array they disappear immediately.

Demo video:

Screen.Recording.2023-04-12.at.17.43.45.mov

What alternative solutions did you explore? (Optional)

None

[MelvinBot]

📣 @arayiksuqiasyan! 📣

Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
2. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
3. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.

Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[arayiksuqiasyan]

Contributor details
Your Expensify account email: arayiksuqiasyan20@gmail.com
Upwork Profile Link: upwork.com/freelancers/~010bf3aba21bc10d87

[MelvinBot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[fedirjh]

What I mean is that our headerMessage should be consistent with the sections.

That's right.

But the value of headersMessage is obviously incorrect, the headersMessage should match the sections, it should be ''

@hellohublot You're correct that the current value of headersMessage is incorrect, and it should be an empty string. If this is the case, we should fix the getHeaderMessage function. Could you please update your proposal with the accurate root cause analysis and a proper solution ?

[chiragsalian]

thanks for the bump. Proposal LGTM. Feel free to create the PR @hellohublot

[MelvinBot]

📣 @hellohublot You have been assigned to this job by @chiragsalian!
Please apply to this job in Upwork and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[MitchExpensify]

Note to myself that timeline bonus will apply here 🎉

[MelvinBot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[MelvinBot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.3-2 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix SearchPage update headerMessage in debounce.updateOptions #17643

If no regressions arise, payment will be issued on 2023-04-28. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[MelvinBot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@fedirjh] The PR that introduced the bug has been identified. Link to the PR:
• [@fedirjh] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@fedirjh] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@MitchExpensify] Determine if we should create a regression test for this bug.
• [@fedirjh] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@MitchExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[fedirjh]

• The PR that introduced the bug has been identified. Link to the PR: Debounce search page and reduce number of tooltips created #3669
• The offending PR has been commented on. Link to comment: Debounce search page and reduce number of tooltips created #3669 (comment)
• A discussion in #expensify-bugs has been started. Link to discussion: https://expensify.slack.com/archives/C049HHMV9SM/p1682124225463719

[MitchExpensify]

Looking for a buddy check on any required addition to test rail @isagoico, I thiiink our existing tests should catch this, do you agree?

[isagoico]

@MitchExpensify I don't think that our current tests would catch this atm BUT I also don't think this is a regular user behavior flow that would affect a big pool of customers.
Imo this is a good example of an edge case issue that can be tested on a monthly basis. Wdty of adding this one to the edge cases list? (Context on edge cases here)

[MitchExpensify]

I love that idea @isagoico !

[isagoico]

Great! We will test these on a monthly basis and post here if the same issue resurfaces.

[MitchExpensify]

Nice! Just to be sure, should I create a regression test in that case @isagoico?

@hellohublot mins applying to this Upwork job for payment? https://www.upwork.com/jobs/~01bee86ec37b82125e Thank you!

[MitchExpensify]

Paid reporter & C+, just waiting on @hellohublot 😄

[hellohublot]

@MitchExpensify Thanks, I have submitted a proposal in upwork, the name and avatar are the same

if you can't find me (I have encountered it before), you can send me an offer directly

[MitchExpensify]

I see this as the only proposal but I found you via search and sent an offer! Thanks again

[isagoico]

Nice! Just to be sure, should I create a regression test in that case @isagoico?

No need! This will be tested directly from the issue. No test steps or test cases are needed.

[hellohublot]

@MitchExpensify Thanks, Accepted

[MitchExpensify]

Great! Thanks everyone.