[$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 [email protected] 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): [email protected]
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: @alitoshmatov

[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

[CyberAndrii]

🚨 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

[dubielzyk-expensify]

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.

I'm not 100% what you mean by "keeping the comment at the position where Edit comment was called", but in general we try to keep things consistent across platforms so if native has a working solution, then we're likely to want to align to that.

[ikevin127]

@dubielzyk-expensify What I mean by that is that currently on staging / production, on all web based platforms (Web, mWeb, Desktop), regardless of the position of the comment in the list, when we press Edit comment, there's no scrolling of the edit composer to the bottom of the list like we do on Native - instead it maintains position where the comment is in the list.

See the very beginning of this video:

alt-solution-after.mov

Whereas, on Native we always scroll the edit composer to the bottom of the list, see this example on current staging:

ios-staging.mp4

[dubielzyk-expensify]

The difference is that on native though we scroll to it because the edited comment goes into the main composer. Whereas on desktop/web we don't do that, we actually add another composer box in place of the comment.

So with that in mind I'm not 100% convinced we should be scrolling to it. Having another look at the main issue to me the only issue is really that when the new edit composer gets added to another comment (web/desktop only) then the last few pixels are missing depending on how the viewport is scrolled.

So if the comment is cut off and then you press Edit, it'll show this bug because it tries to put the edited comment in view, but is cutting off the last few pixels. To me it's almost like it's aligning to the wrong thing.

After playing around on my own machine I kinda feel like this issue isn't even worth fixing. It feels so minor. Keen to hear what @Expensify/design thinks.

[shawnborton]

Yeah I generally agree with that, I would be comfortable just closing this out.

[CyberAndrii]

To quickly summarise my proposal, please note that this issue is caused by the composer having an incorrect font size for a split second (see that emojis are overlapping on the screenshot below), which makes the composer briefly appear smaller. This happens with all emoji messages, not just the most recent one. Later when it resizes to the correct size, the bottom part of the edit composer appears cut off. So maybe you may want to fix this

Video

Notice that editing text-only messages is smooth, but editing messages that contain emojis isn't

Screen.Recording.2025-01-13.at.10.48.15.mov

[shawnborton]

Oh interesting... that seems like it would be worth fixing - the small jump in size/height does not feel very premium to me.

[dannymcclain]

Yeah that little jump doesn't feel great.

[Christinadobrzyn]

@alitoshmatov can you check out these proposals please. TY!

[dubielzyk-expensify]

I feel like we're discussing two separate issues here, but on the jumping composer issue I agree that we should fix that.

[melvin-bot]

@Christinadobrzyn, @alitoshmatov Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Christinadobrzyn]

Ah, okay, @CyberAndrii, could you report the issue you described in #Expensify-bugs to create a new GH? I think you can also include your proposal for a fix.

Once that's complete, it sounds like we're good to close this issue without a fix and we'll focus on the other one you've described.

Feel free to reach out if I'm missing something or if you have any questions!

[CyberAndrii]

This issue (where the composer is cut off) and #55068 (comment) have the same root cause. Fixing one will also fix the other. So I think we're good doing it here? Also I don't have access to #Expensify-bugs (would like to be invited if that's possible).

[alitoshmatov]

This issue (where the composer is cut off) and #55068 (comment) have the same root cause. Fixing one will also fix the other.

I agree. Seems like we should focus on composer height being smaller briefly which is causing both of the issues.

[alitoshmatov]

I think based on this new issue of the same root cause your proposals are not complete @ikevin127 @ishakakkad

[alitoshmatov]

@CyberAndrii Thank you for proposal, your RCA is correct and solution works well. I didn't like that top and bottom paddings are different when on emoji is in the input, however due to emojis not occupying the whole line height emojis are visually centered even with different paddings.

I think we can go with @CyberAndrii 's proposal

C+ reviewed 🎀 👀 🎀

[melvin-bot]

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

[melvin-bot]

📣 @CyberAndrii 🎉 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 📖

[Christinadobrzyn]

reviewing PR - #55438

[Christinadobrzyn]

reviewing PR - #55438

[Christinadobrzyn]

reviewing PR - #55438