[HOLD for payment 2024-06-03] [$250] mWeb - Chat - In edit comment, changed skin tone is not applied

[lanitochka17]

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.73
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4554707
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Tap in a report
3. Send a message
4. Tap emoji picker in compose box and change the skin tone
5. Enter 👍 and note changed skin tone is applied
6. Clear the text
7. In step 3, long press the message sent and tap edit comment
8. Tap enter key and move cursor to second line.
9. Enter 👍 and note changed skin tone is not applied

Expected Result:

In edit comment, changed skin tone must be applied

Actual Result:

In edit comment, changed skin tone is not applied

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

Bug6479206_1715597160442.Skin.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013cd26a26b248adb5
• Upwork Job ID: 1790054359169802240
• Last Price Increase: 2024-05-13
• Automatic offers:
• s77rt | Reviewer | 0
• bernhardoj | Contributor | 0

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

Triggered auto assignment to @garrettmknight (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.

[lanitochka17]

@garrettmknight FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[bernhardoj]

Proposal

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

The preferred skin tone doesn't update in edit composer, but updates in main composer.

What is the root cause of that problem?

The preferred skin tone value is passed from the ReportActionItem to the composer.

App/src/pages/home/report/ReportActionItem.tsx

Lines 1021 to 1025 in 3bdb08d

	export default withOnyx<ReportActionItemProps, ReportActionItemOnyxProps>({
	preferredSkinTone: {
	key: ONYXKEYS.PREFERRED_EMOJI_SKIN_TONE,
	initialValue: CONST.EMOJI_DEFAULT_SKIN_TONE,
	},

App/src/pages/home/report/ReportActionItem.tsx

Lines 675 to 676 in 3bdb08d

	// Avoid defining within component due to an existing Onyx bug
	preferredSkinTone={preferredSkinTone}

And ReportActionItem use a memo to optimize the rendering, but we haven't consider the case for the preferred skin tone, so even after it's updated, the component never re-renders.

App/src/pages/home/report/ReportActionItem.tsx

Lines 1053 to 1087 in 3bdb08d

	memo(ReportActionItem, (prevProps, nextProps) => {
	const prevParentReportAction = prevProps.parentReportAction;
	const nextParentReportAction = nextProps.parentReportAction;
	return (
	prevProps.displayAsGroup === nextProps.displayAsGroup &&
	prevProps.isMostRecentIOUReportAction === nextProps.isMostRecentIOUReportAction &&
	prevProps.shouldDisplayNewMarker === nextProps.shouldDisplayNewMarker &&
	lodashIsEqual(prevProps.emojiReactions, nextProps.emojiReactions) &&
	lodashIsEqual(prevProps.action, nextProps.action) &&
	lodashIsEqual(prevProps.iouReport, nextProps.iouReport) &&
	lodashIsEqual(prevProps.report.pendingFields, nextProps.report.pendingFields) &&
	lodashIsEqual(prevProps.report.isDeletedParentAction, nextProps.report.isDeletedParentAction) &&
	lodashIsEqual(prevProps.report.errorFields, nextProps.report.errorFields) &&
	prevProps.report?.statusNum === nextProps.report?.statusNum &&
	prevProps.report?.stateNum === nextProps.report?.stateNum &&
	prevProps.report?.parentReportID === nextProps.report?.parentReportID &&
	prevProps.report?.parentReportActionID === nextProps.report?.parentReportActionID &&
	// TaskReport's created actions render the TaskView, which updates depending on certain fields in the TaskReport
	ReportUtils.isTaskReport(prevProps.report) === ReportUtils.isTaskReport(nextProps.report) &&
	prevProps.action.actionName === nextProps.action.actionName &&
	prevProps.report.reportName === nextProps.report.reportName &&
	prevProps.report.description === nextProps.report.description &&
	ReportUtils.isCompletedTaskReport(prevProps.report) === ReportUtils.isCompletedTaskReport(nextProps.report) &&
	prevProps.report.managerID === nextProps.report.managerID &&
	prevProps.shouldHideThreadDividerLine === nextProps.shouldHideThreadDividerLine &&
	prevProps.report?.total === nextProps.report?.total &&
	prevProps.report?.nonReimbursableTotal === nextProps.report?.nonReimbursableTotal &&
	prevProps.linkedReportActionID === nextProps.linkedReportActionID &&
	lodashIsEqual(prevProps.report.fieldList, nextProps.report.fieldList) &&
	lodashIsEqual(prevProps.policy, nextProps.policy) &&
	lodashIsEqual(prevProps.transactionThreadReport, nextProps.transactionThreadReport) &&
	lodashIsEqual(prevProps.reportActions, nextProps.reportActions) &&
	lodashIsEqual(prevProps.transaction, nextProps.transaction) &&
	lodashIsEqual(prevParentReportAction, nextParentReportAction)
	);

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

Check for preferred skin tone in the memo.
prevProps.preferredSkinTone === nextProps.preferredSkinTone &&.

What alternative solutions did you explore? (Optional)

Move the preferred skin tone onyx connection to edit composer component.

as pointed out by the comment, the reason we pass the preferred skin tone from ReportActionItem to edit composer is because it causes a crash because the app tries to focus on the edit composer but it's not rendered yet because delayed by withOnyx (ref). However, I can't reproduce it anymore, but to be safe, we can set an initial value to it just like what we already did or use useOnxy to be safer.

[melvin-bot]

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

[melvin-bot]

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

[s77rt]

@bernhardoj Thanks for the proposal. Your RCA is correct. The onyx bug technically is still reproducible as the HOC can still return null. It's probably hard to reproduce now due to caching. But also the use of initialValue prevents the bug since we will have a value to render initially. We can now move the onyx subscription to ReportActionItemMessageEdit and to be extra safe we should use the useOnyx hook as it does not suffer from the problem in the HOC.

🎀 👀 🎀 C+ reviewed
Link to proposal

[melvin-bot]

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

[melvin-bot]

📣 @s77rt 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @bernhardoj 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer 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 📖

[bernhardoj]

PR is ready

cc: @s77rt

[melvin-bot]

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

[melvin-bot]

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

• Fix changed skin tone is not applied in edit composer #42181

If no regressions arise, payment will be issued on 2024-06-03. 🎊

For reference, here are some details about the assignees on this issue:

• @s77rt requires payment automatic offer (Reviewer)
• @bernhardoj requires payment automatic offer (Contributor)

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

• [@s77rt] The PR that introduced the bug has been identified. Link to the PR:
• [@s77rt] 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:
• [@s77rt] 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:
• [@s77rt] Determine if we should create a regression test for this bug.
• [@s77rt] 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.
• [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[s77rt]

• The PR that introduced the bug has been identified: Refactor ReportActionItem to use hooks #18809
• The offending PR has been commented on: Refactor ReportActionItem to use hooks #18809 (comment)
• A discussion in #expensify-bugs has been started: Not needed
• Determine if we should create a regression test for this bug: Yes

---

Regression Test Proposal

1. Go to any report
2. Send a message
3. Right click (or long press) on the message and select "Edit comment"
4. Type any emoji code e.g. :+1:
5. Change the skin tone from the emoji picker button
6. Type any emoji code e.g. :+1:
7. Verify that newly inserted emoji has the updated skin tone color

[garrettmknight]

All paid up and QA'd, closing!