[$250] mWeb/Chrome -Chat - When adding emoji in multiline message composer is not completelly autoscrolled

[lanitochka17]

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.44-0
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/5043700&group_by=cases:section_id&group_order=asc&group_id=306201
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the staging.new.expensify.com website
2. Open any chat
3. Start typing a multiline message until a scroller is displayed
4. In the next line, add an emoji
5. Verify the compose box is autoscrolled to the bottom and the emoji is not overlapped

Expected Result:

When adding an emoji in a multiline message, the compose box should be scrolled to the bottom so the emoji is not overlapped

Actual Result:

When the scrollbar is displayed in a multiline message and the user adds an emoji in a new line, the compose box is not autoscrolled to the bottom and the emoji is overlapped until the user scrolls down

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

Bug6623459_1727975277132.Multiemoji.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021843658720204692310
• Upwork Job ID: 1843658720204692310
• Last Price Increase: 2024-10-08

Issue Owner

Current Issue Owner: @s77rt

[melvin-bot]

Triggered auto assignment to @OfstadC (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]

@OfstadC 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

[OfstadC]

I tested this end of last week and then got side tracked. Reviewing again

[OfstadC]

i believe this is ND Quality - posted in Slack to confirm

[melvin-bot]

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

[melvin-bot]

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

[Skalakid]

Hello, I'm Michał from SWM, an expert agency, and I will investigate this issue

[s77rt]

@OfstadC Please assign @Skalakid

[Skalakid]

Hello, I've investigated this topic, and two problems are causing this issue.

The first is connected to our current scroll-into-view logic inside the Live Markdown library. When trying to insert the emoji from the modal, we add the emoji and the space after it to the input value. Because of this space, the target element for scrolling-into-view is the text node, which has a different line height than the emoji. To fix it, we can take the parent line element and scroll the view into it. Also, we can use the #45885 (comment) fix and add some bottom padding on the scroll, like 4px.

The second problem is connected to default text input behavior. By default, HTML input/text area elements don't include padding at the bottom when scrolling text into view. The same happens in the native RN TextInput component. Because of that, the input isn't scrolled fully to the bottom when inserting the new line and adding text there.

Video

Screen.Recording.2024-10-08.at.18.39.50.mov

Because of that, I think we shouldn't care about scrolling the input fully to the bottom because it's the default input behavior. Instead, let's focus on scrolling input so emojis in the line don't overlap in every scenario. What are your thoughts on this?

[Skalakid]

Here is a PR with the fix

[melvin-bot]

@OfstadC, @s77rt, @Skalakid Huh... This is 4 days overdue. Who can take care of this?

[s77rt]

PR still under review

[melvin-bot]

@OfstadC @s77rt @Skalakid this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[s77rt]

Expensify/react-native-live-markdown#514 is merged. Waiting on the App PR for the upgrade

[melvin-bot]

@OfstadC, @s77rt, @Skalakid Whoops! This issue is 2 days overdue. Let's get this updated quick!

[s77rt]

@Skalakid Do you have an ETA for the E/App PR?

[Skalakid]

Hi, sorry I had to prioritize other tasks and didn't have time to do it. Creating the PR with a bump right now

[Skalakid]

Here is the PR

[melvin-bot]

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