[Due for payment 2025-02-19] [$250] Chat - Composer is cutted of when editing message with two lines of emojis.

[IuliiaHerets]

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: 9.0.83-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers): ibellicotest+171@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome / Windows 10 - Chrome
App Component: Other

Action Performed:

1. Open the staging.new.expensify.com website.
2. Open any chat.
3. Add emojis on the same line on compose box, until reaching a second line on the message.
4. Send the message.
5. Long tap on the just sent message and select "Edit Message"
6. Check that edition composer is fully displayed.

Expected Result:

Edition composer should be fully visible when editing messgae with two lines of emojis.

Actual Result:

Composer is displayed cutted off when editing a message with two lines of emojis on it.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6710951_1736514493645.Cutted.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021877823395464489812
• Upwork Job ID: 1877823395464489812
• Last Price Increase: 2025-01-10
• Automatic offers:
• CyberAndrii | Contributor | 105706338

Issue Owner

Current Issue Owner: @Christinadobrzyn

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[Christinadobrzyn]

I can reproduce with the steps in the OP - I think this can be External .

[ishakakkad]

Proposal

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

When editing the recent message, which contains two lines of emojis, it gets hidden behind the scrollbar.

What is the root cause of that problem?

Due to dyanamic height of the chat messages sometimes scrolling by index not working as expected and in edit mode recent chat message hidden behind the scrollbar.
https://github.com/Expensify/App/blob/main/src/pages/home/report/ReportActionItemMessageEdit.tsx#L528-L531

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

To fix this issue we can scroll to bottom when we edit to recent(latest) message. For this we need to make changes here.

InteractionManager.runAfterInteractions(() => {
  requestAnimationFrame(() => {
      if (index === 0) {
          reportScrollManager.scrollToBottom();
      } else {
          reportScrollManager.scrollToIndex(index, true);
      }
  });
});

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

NA

What alternative solutions did you explore? (Optional)

NA

[andriivitiv]

🚨 Edited by proposal-police: This proposal was edited at 2025-01-14 14:37:54 UTC.

Proposal

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

Composer is cut off when editing a message with more than 1 line of emojis

What is the root cause of that problem?

Initially, the line height is set to 20px. When text contains only emojis AND spans multiple lines, the line height is adjusted to 35px

App/src/components/Composer/implementation/index.tsx

Line 351 in fb487a5

textContainsOnlyEmojis && hasMultipleLines ? styles.onlyEmojisTextLineHeight : {},

The issue is that the hasMultipleLines variable is initially set to false on the first render. As a result, the line height starts at 20px instead of the required 35px (see screenshot 2). Then it gets corrected in a subsequent render via this callback

App/src/components/Composer/implementation/index.tsx

Lines 374 to 377 in fb487a5

	onContentSizeChange={(e) => {
	setPrevHeight(e.nativeEvent.contentSize.height);
	setHasMultipleLines(e.nativeEvent.contentSize.height > variables.componentSizeLarge);
	}}

This resize (from shorter to taller) causes the edit composer to be partially hidden under the main composer

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

Completely remove the hasMultipleLines state from the Composer component

App/src/components/Composer/implementation/index.tsx

Line 76 in fb487a5

const [hasMultipleLines, setHasMultipleLines] = useState(false);

The line height should consistently be set to 35px for text containing only emojis, regardless of whether the text spans a single or multiple lines. Even when the line height is 20px for single-line text, emojis are still displayed as if the line height is 35px.

However, you will notice that the padding above the Send button and emojis is larger than below. See the discussion here: #47547 (comment). To fix this, we need to adjust the getComposeTextAreaPadding function to reduce the top padding when the text contain only emojis

function getComposeTextAreaPadding(isComposerFullSize: boolean, textContainsOnlyEmojis: boolean): TextStyle {
    let paddingTop = 5;
    let paddingBottom = 5;
    // Issue #26222: If isComposerFullSize paddingValue will always be 5 to prevent padding jumps when adding multiple lines.
    if (!isComposerFullSize) {
        paddingTop = 8;
        paddingBottom = 8;
    }
    // or just
    // if (textContainsOnlyEmojis) {
    if (!isComposerFullSize && textContainsOnlyEmojis) {
        paddingTop = 3;
    }
    return {paddingTop, paddingBottom};
}

And pass textContainsOnlyEmojis here

App/src/components/Composer/implementation/index.tsx

Line 346 in fb487a5

StyleUtils.getComposeTextAreaPadding(isComposerFullSize),

StyleUtils.getComposeTextAreaPadding(isComposerFullSize, textContainsOnlyEmojis),

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

N/A

[ikevin127]

Proposal

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

Edition composer should be fully visible when editing message with two or more lines of emojis.

What is the root cause of that problem?

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

Lines 528 to 532 in fb487a5

	InteractionManager.runAfterInteractions(() => {
	requestAnimationFrame(() => {
	reportScrollManager.scrollToIndex(index, true);
	});
	});

The root cause originates from the edit composer onFocus logic which calls reportScrollManager.scrollToIndex(index, true), the problem being the second argument which is true, if we follow the scrollToIndex function, we can notice that when isEditing is true, the scroll function will never be called when entering edit mode since the function returns early.

This seems to have been done on purpose on non-Native platforms to not scroll when entering edit mode, but obviously this emoji edge case was missed.

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

We can simlpy remove the second argument (true) from the scrollToIndex() call in this block which will make sure to always scroll the edit composer into view whenever a comment is edited.

Note

This solution will always scroll the edit composer to the bottom of the report screen instead of keeping the comment at the position where Edit comment was called, see video below for example.

Note that on the index.native.ts version of scrollToIndex() we don't even have the isEditing as 2nd argument since the main solution I'm proposing here is already the norm on native devices, meaning always scroll edit composer at the bottom of report screen when entering edit mode.

MacOS: Chrome (with main solution fix) / iOS: Native (current staging behaviour)

MacOS: Chrome	iOS: Native
main-solution-after.mov	ios-staging.mp4

cc @Expensify/design for input on whether this solution preferred from a UX / UI point of view compared to keeping the comment at the position where Edit comment was called, since the first is already the norm on Native.

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

None since this is UI / UX behaviour.

What alternative solutions did you explore? (Optional)

Similar to what the first proposal suggested, but more compact in terms of less lines of code, we can keep this block the same, but modify the scrollToIndex function to not return early when index === 0 which means it will scroll edit composer into view only if the comment is the latest one.

Code changes would look like this:

const scrollToIndex = useCallback(
    (index: number, isEditing?: boolean) => {
-        if (!flatListRef?.current || isEditing) {
+        if (!flatListRef?.current || (isEditing && index !== 0)) {
            return;
        }

        flatListRef.current.scrollToIndex({index, animated: true});
    },
    [flatListRef],
);

Note that this will maintain current staging behaviour of no scrolling when isEditing === true, but only for comments that are not index 0 (latest).

MacOS: Chroms (Alternative solution result)

alt-solution-after.mov