[HOLD for payment 2022-12-15] Emojis get to the normal size after a brief moment

[kavimuru]

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. Go to any Chat
3. Add emojis on 1st line > leave 2nd line blank > add emojis on 3rd line
4. Send message

Expected Result:

Emojis should directly go to the normal size without any delay

Actual Result :

Emojis take a few milliseconds to reach their final size

Workaround:

unknown

Platform:

Where is this issue occurring?

• Web
• Android
• Mobile Web

Version Number: 1.2.29-6
Reproducible in staging?: y
Reproducible in production?: y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

bug_1.mp4

Recording.984.mp4

Expensify/Expensify Issue URL:
Issue reported by: @daraksha-dk
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1668980022543179

View all open jobs on GitHub

[melvin-bot]

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

[aldo-expensify]

Reproduced, weirdly this happens only if you add the emojis like it was mentioned and it doesn't happen if you just add a single emoji

[aldo-expensify]

In the case of two emojis in different lines changing size after a moment, it seems to happen after we get the response from the server:

Screen.Recording.2022-11-21.at.2.03.35.PM.mov

If we disable the connection, we see that they are small and they stay small.

[aldo-expensify]

Screen.Recording.2022-11-21.at.6.22.39.PM.mov

The optimistic report action gets text by calling ExpensiMark.htmlToText on html here:

App/src/libs/ReportUtils.js

Lines 625 to 626 in 00d7c61

	const textForNewComment = isAttachment ? '[Attachment]'
	: parser.htmlToText(htmlForNewComment);

This result is incorrect, the html content is 🥶 <br /><br />🥶 (notice the whitespace before the first <br />, but the resulting text is 🥶 🥶, which only contains 2 whitespaces.

This makes the check here fail in detecting that the html and text content are the same if we replace <br /> by . This ends up making it render the comment using <RenderHTML here instead of <Text here.

When we get the ReportAction from the backend, this the text has been correctly derived from html and contains 3 spaces:

[aldo-expensify]

To solve this, I think we should change the regex here:

https://github.com/Expensify/expensify-common/blob/dd66d931aeffe18cdcffab8e7d05af32f3ef7ad1/lib/ExpensiMark.js#L290

for

                regex: /<br[^>]*>/gi,

The current regex is replacing multiple consecutive <br /> for a single whitespace, meanwhile the server doesn't seem to be doing the same. The server seems to be replacing each <br /> by a whitespace:

[aldo-expensify]

PR up

[aldo-expensify]

There may be some other things to change (including API), I posted a proposed solution in slack to get some feedback

[aldo-expensify]

I'm still investigating this. I trying to test push notification (urban airship) to see the impact of replacing <br /> by \n instead of in the web API, but I haven't been able to test it reliably in dev

I plan to spend some time on this today to finish the PRs

[aldo-expensify]

The PR are under review.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

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

• Message html to text and last message (LHN) fixes #12968

If no regressions arise, payment will be issued on 2022-12-15. 🎊

After the hold period, please check if any of the following need payment for this issue, and if so check them off after paying:

• 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

[melvin-bot]

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:

• [@aldo-expensify] The PR that introduced the bug has been identified. Link to the PR:
• [@aldo-expensify] 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:
• [@aldo-expensify] 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:
• [] A regression test has been added or updated so that the same bug will not reach production again. Link to the GH issue for creating the test here:

[aldo-expensify]

This GH issue was reported by a contributor (Daraksha) so I think we still have to pay them?

https://expensify.slack.com/archives/C049HHMV9SM/p1668980022543179

I'll reapply the bug to get help from BugZero team

[aldo-expensify]

Added @adelekennedy back instead of the reapplying the label because she has a bit of context already

[adelekennedy]

@daraksha-dk will you apply here so I can pay you for the reporting bonus?

[daraksha-dk]

Applied! @adelekennedy

[adelekennedy]

Woo! @daraksha-dk just hired you, once you accept I'll pay out and close this!

[adelekennedy]

paid and closed!