[HOLD for payment 2024-02-14] [$500] Expense - Approver email from Next step message receives error when pasted in login field

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

---

Version Number: 1.4.24-7
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
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

Precondition:

• User is an employee of Collect workspace.
• The Collect workspace has admin, approver and employee.

1. [Employee] Create a manual request from the workspace chat.
2. [Admin] Go to workspace chat with Employee.
3. [Admin] Click on the expense preview to open expense report.
4. [Admin] Copy the approver email from Next step message.
5. [Admin] Paste the email in the login field.

Expected Result:

No validation error will be thrown as the email copied is a valid email.

Actual Result:

The email is a valid email but validation error shows up in the login field.

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6340063_1705059929889.bandicam_2024-01-11_10-09-45-385.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01b45edbff007b5878
• Upwork Job ID: 1745790923128475648
• Last Price Increase: 2024-01-26
• Automatic offers:
• alitoshmatov | Reviewer | 28129669
• tienifr | Contributor | 28129670

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[bernhardoj]

Proposal

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

Copying the email from next step message and use it as the login will fail the login validation.

What is the root cause of that problem?

The email in next step message contains a zero width character, specifically zero width space that is added from prefixMailSeparatorsWithBreakOpportunities.

App/src/libs/EmailUtils.ts

Lines 10 to 28 in 964548a

	/**
	* Prepends a zero-width space (U+200B) character before all `.` and `@` characters
	* in the email address to provide explicit line break opportunities for consistent
	* breaking across platforms.
	*
	* Note: as explained [here](https://github.com/Expensify/App/issues/30985#issuecomment-1815379835),
	* this only provides opportunities for line breaking (rather than forcing line breaks) that shall
	* be used by the platform implementation when there are no other customary rules applicable
	* and the text would otherwise overflow.
	* @param email - The email address to be sanitized
	* @returns The email with inserted line break opportunities
	*/
	function prefixMailSeparatorsWithBreakOpportunities(email: string) {
	return email.replace(
	/([.@])/g,
	// below: zero-width space (U+200B) character
	'​$1',
	);
	}

The motivation behind that is explained well in the comment.

So, when we use this as the login, the validation will throw an error because zero width scpae is not a valid character.

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

We can replace all zero width space when copying the text in SelectionScraper.

App/src/libs/SelectionScraper/index.ts

Lines 113 to 114 in 964548a

	if (dom.type.toString() === 'text' && dom instanceof DataNode) {
	data = Str.htmlEncode(dom.data);

data.replaceAll('\u200b', '')

Another zero width character is ZWJ with unicode of \u200d which maybe we can include too with any other zero width character.

or remove prefixMailSeparatorsWithBreakOpportunities if we don't want it anymore

[shubham1206agra]

Proposal

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

Expense - Approver email from Next step message receives error when pasted in login field.

What is the root cause of that problem?

The email in next step message contains a zero-width character, which is zero-width space character (so that user wouldn't notice this) that is added using prefixMailSeparatorsWithBreakOpportunities.

App/src/libs/EmailUtils.ts

Lines 10 to 28 in 964548a

	/**
	* Prepends a zero-width space (U+200B) character before all `.` and `@` characters
	* in the email address to provide explicit line break opportunities for consistent
	* breaking across platforms.
	*
	* Note: as explained [here](https://github.com/Expensify/App/issues/30985#issuecomment-1815379835),
	* this only provides opportunities for line breaking (rather than forcing line breaks) that shall
	* be used by the platform implementation when there are no other customary rules applicable
	* and the text would otherwise overflow.
	* @param email - The email address to be sanitized
	* @returns The email with inserted line break opportunities
	*/
	function prefixMailSeparatorsWithBreakOpportunities(email: string) {
	return email.replace(
	/([.@])/g,
	// below: zero-width space (U+200B) character
	'​$1',
	);
	}

As we are not removing zero-width characters in LoginForm as we are doing in every other form, which uses StringUtils.removeInvisibleCharacters in FormProvider definition of validation and submit methods.

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

Remove the zero-width characters using StringUtils.removeInvisibleCharacters in validateAndSubmitForm, and validate method in LoginForm.

[tienifr]

Proposal

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

The email is a valid email but validation error shows up in the login field.

What is the root cause of that problem?

In here, we're appending zero width character into the email so that it breaks properly on web, more explanation here.

This causes the validation to fail in login page.

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

I'm expanding on the suggested approach

1. Add testID="email-with-break-opportunities" to the Text component here to indicate what type of tag this is (we could name it next-step-email but I prefer email-with-break-opportunities because then we can reuse it wherever we want to target an email with break opportunities). This is an approach widely used in the app such as in here

2. In here, check if the parent of this text has the email-with-break-opportunities data-testid, if yes that means this is part (or whole) of an email that we prefixed with break opportunities and we know we should remove those added break opportunities from it when copying.

if (dom?.parent?.attribs?.[tagAttribute] === "email-with-break-opportunities") {
    data = data.replaceAll('\u200b', '');
}

(we can expand to remove all zero width characters if we want to)
(The attribs[tagAttribute] approach is widely used in SelectionScraper, like in here)

3. In other places where emails with break opportunities are used, also use the testID="email-with-break-opportunities" on the Text element, for example I can see another place here

4. We can optionally update so that we'll only do the zero width character replacement in web/desktop because those are the only places that we need the logic now (native platforms have no problems with breaking the email properly). That can be done by make prefixMailSeparatorsWithBreakOpportunities a no-op in native platforms.

We can additionally remove the invisible characters before validation/submission in the login page using StringUtils.removeInvisibleCharacters, so we don't accidentally show errors for emails with invisible characters copied from other sources.

What alternative solutions did you explore? (Optional)

I don't think this is good practice because:

• It can cause the copied text to fail randomly on other forms in the web (our form here is an example) because the zero width character is not common and most forms out there won't detect and remove it properly. And when it fails the user won't know why because it looks like any other email
• It causes weird things to happen. For example when you copied this text hello​@expensify.com which contains a zero width character before @, if you delete characters one by one when coming to the o before @, you'll have to delete twice for it to work (one delete is for the invisible character)
• We also shouldn't remove the zero width character when copying the text as suggested above because there might be valid use cases for it elsewhere in the app, like in messages

I think what we should do instead is to use word break opportunity tags (which is also mentioned as an alternative in this original explanation). The only drawback mentioned is that it only works for web. I think that's fine because all platforms like iOS and Android already have it built in, they break the lines properly, the issue is only for web. And this approach doesn't have all the drawbacks mentioned above.

More info on why the word break opportunity tags is better here https://medium.com/@igorshevchenko/wbr-is-better-than-zero-width-space-128f4bedc5e0#:~:text=According%20to%20the%20HTML5%20spec,intended%20for%20invisible%20word%20separation.
To quote:

But now I found that there’s issue which might make me switch back to using <wbr>: some smarty-pants IDE insert ZWSP “as is” when copying text from browser to, let’s say, search field. Nothing found. Disaster. Failure. Cataclysm.

[MitchExpensify]

Proposals ready for you to check out @alitoshmatov