[Due for payment 2025-09-17] [$250] Login - Email ID with emoji is allowed to proceed & emoji changes into random alphabets

[jponikarchuk]

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

---

Version Number: V9.1.77-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/6444482
Email or phone of affected tester (no customers): dreamnitethedragon@gma😆il.com
Issue reported by: Applause Internal Team
Device used: Redminote 10s android 13
App Component: Other

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Enter email - dreamnitethedragon@gma😆il.com
3. Tap continue
4. Tap Go back

Expected Result:

Email id with emoji must display error and must not allow user to continue.

Actual Result:

Email id with emoji is allowed to proceed and emoji changes into random alphabets.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021942675830584234660
• Upwork Job ID: 1942675830584234660
• Last Price Increase: 2025-07-15

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @OfstadC

[melvin-bot]

Triggered auto assignment to @OfstadC (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[Krishna2323]

Proposal

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

Login - Email ID with emoji is allowed to proceed & emoji changes into random alphabets

What is the root cause of that problem?

• isValidEmail function does not check for emoijs:
  https://github.com/Expensify/expensify-common/blob/d94b054369939c823d37fbcdd7435c22063d183a/lib/str.ts#L399-L409

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

• We should update it to:

function isValidEmail(str) {
    const emailRegex = Constants.CONST.REG_EXP.EMAIL;
    const emojiRegex = Constants.CONST.REG_EXP.EMOJI_RULE;

    return emailRegex.test(str) && !emojiRegex.test(str);
}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• We can update these tests for isValidEmail and pass different values to test the validation.

What alternative solutions did you explore? (Optional)

• Or we can create a ASCII_ONLY regex and use that for validation:

function isValidEmail(str) {
    const emailRegex = Constants.CONST.REG_EXP.EMAIL;
    const asciiOnlyRegex = /^[\x00-\x7F]+$/; // Or `/^[\x00-\x7F]+$/;`

    return emailRegex.test(str) && asciiOnlyRegex.test(str);
}

Result

[dmkt9]

Proposal

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

Email ID with emoji is allowed to proceed & emoji changes into random alphabets

What is the root cause of that problem?

1. Since the inputMode we use is set to "email", any non-ASCII characters in the domain part are automatically converted to Punycode (i.e., the xn--... format).
   

   App/src/pages/signin/LoginForm/BaseLoginForm.tsx

   Line 264 in 665f42d

   inputMode={CONST.INPUT_MODE.EMAIL}

2. We use the isValidEmail function to validate the input, but this function does not check for cases where the domain has already been converted to Punycode, so it still returns true (valid).
   https://github.com/Expensify/expensify-common/blob/fc88a016e2bb1813043cede8f5fc98ae48cd538a/lib/str.ts#L407-L409

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

• To address this issue, we have a few possible options:

1. Option 1: Remove inputMode="email".
   

   App/src/pages/signin/LoginForm/BaseLoginForm.tsx

   Line 264 in 665f42d

   inputMode={CONST.INPUT_MODE.EMAIL}

inputMode={CONST.INPUT_MODE.TEXT}

2. Option 2: In the isValidEmail function, immediately return false if the domain contains Punycode.
   https://github.com/Expensify/expensify-common/blob/fc88a016e2bb1813043cede8f5fc98ae48cd538a/lib/str.ts#L407-L409

// Example
isValidEmail(str: string): boolean {
    const strArray = str.split('@');
    if (strArray.length !== 2 || strArray[1] === '') {
        return false;
    }
    if(somePunnycodeReg.test(strArray[1])) { //pseudocode
        return false
    }
    return !!String(str).match(Constants.CONST.REG_EXP.EMAIL);
},

3. Option 3: Use an external library like punycode to convert the domain back to its original form before testing it with the regex, or implement a similar function manually.

isValidEmail(str: string): boolean {
    const strArray = str.split('@');
    if (strArray.length !== 2 || strArray[1] === '') {
        return false;
    }
    const unicodeDomainStr = punycode.decode(strArray[1]);
    return !!String(`${strArray[0]}@${unicodeDomainStr}`).match(Constants.CONST.REG_EXP.EMAIL);
},

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add test for isValidEmail function

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[melvin-bot]

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

[dangrous]

Happy to help with internal review here when it's ready!

[Ollyws]

@Krishna2323 Your proposal won't work because, as @dmkt9 pointed out the domain is returned containing punycode.

@dmkt9 The problem with removing the email input mode is a different keyboard will be displayed for mobile devices, and returning invalid for emails that contain punycode doesn't seem like a great solution because alot of punycode strings are simple and common tda for example is a punycode string.