[HOLD for payment 2024-11-05] [$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
• [x] Android: mWeb Chrome
• [ ] iOS: Native
• [ ] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/cced6122-2541-4ada-b320-aa81abef2533

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

[melvin-bot[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[bot]]

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

[melvin-bot[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 https://github.com/Expensify/App/issues/45885#issuecomment-2363453857 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

https://github.com/user-attachments/assets/a952a2bc-e7e6-44e1-b8d1-f873538c9569

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[bot]]

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

[s77rt]

PR still under review

[melvin-bot[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]

https://github.com/Expensify/react-native-live-markdown/pull/514 is merged. Waiting on the App PR for the upgrade

[melvin-bot[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[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

• https://github.com/Expensify/App/pull/51311

If no regressions arise, payment will be issued on 2024-11-05. :confetti_ball:

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

• @s77rt requires payment through NewDot Manual Requests
• @Skalakid does not require payment (Contractor)

[melvin-bot[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.
• [ ] [@OfstadC] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[OfstadC]

@s77rt Please complete checklist before 2024-11-05 so I can issue payment. Thank you 😃

[s77rt]

On the schedule 😁

[s77rt]

• The PR that introduced the bug has been identified: n/a (Upstream bug and it seems to be a problem since day one)
• The offending PR has been commented on: n/a
• A discussion in #expensify-bugs has been started: Not needed
• Determine if we should create a regression test for this bug: No (low priority)

[melvin-bot[bot]]

Payment Summary

Upwork Job

• Reviewer: @s77rt due $250 via manual NewDot request
• Contributor: @Skalakid is from an agency-contributor and not due payment

BugZero Checklist (@OfstadC)

• [x] I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• [x] I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1843658720204692310/hired)
• [x] I have paid out the Upwork contracts or cancelled the ones that are incorrect
• [x] I have verified the payment summary above is correct

[OfstadC]

Payment Summary above looks good 👍

[JmillsExpensify]

$250 approved for @s77rt