[$250] Room - Pasting long text in description not scrolled to bottom & cursor shown at middle.

[izarutskaya]

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.10
Reproducible in staging?: Y
Reproducible in production?: Y
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Tap on any room chat (#admin)
3. Paste any long text in compose box and note user scrolled to end showing cursor at end.
4. Tap on header
5. Tap room description
6. Paste the same long text in description field and note user not scrolled to end and cursor not shown at end.
7. Tap private notes
8. Paste the same long text in Private Notes field and note user scrolled to end and cursor shown at end.

Expected Result:

Pasting long text in description must scrolled to bottom & cursor must be shown at end.

Actual Result:

Pasting long text in description not scrolled to bottom & cursor is shown in middle of text instead of end.

This happens in task description and in other description field across the app.

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

Bug6548548_1721552717658.cur.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~013fba32c1ac87d746
• Upwork Job ID: 1818439983332130443
• Last Price Increase: 2024-09-18

Issue Owner

Current Issue Owner: @mollfpr

[melvin-bot]

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

[izarutskaya]

We think this issue might be related to the #vip-vsb

[abzokhattab]

Edited by proposal-police: This proposal was edited at 2024-08-13 07:50:10 UTC.

Proposal

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

Pasting long text in description not scrolled to bottom

What is the root cause of that problem?

In the private notes page, we use useHtmlPaste on the input ref, which handles moving the cursor when pasting from clipboard. however we don't do that in the description page

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

To ensure consistency, we should call the useHtmlPaste(reportDescriptionInputRef); inside the room and task description pages as well.

We can also do that in other places if needed.

alternatively

For a global solution, we can use the useHtmlPaste inside the TextInput and we should add a prop disableUseHtmlPaste that would disable the hook call ... this would be useful for the compose where we pass the onPaste function to the hook, this prop can be used in other cases as well.

Another solution

OR more specifically since the issue occurs when the isMarkdownEnabled is enabled then we can enable the useHtmlPaste hook when the markdown is enabled.

[mallenexpensify]

Checking a couple other cursor-related issues

• [Pay meow][$250] Web - Composer - Cursor positioned at the start if pasting text which contains a new line #42216
• [Awaiting checklist] [$250] Composer - Cursor Position Resets to Start of Message on Page Refresh #44259

[kpadmanabhan]

Proposal

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

Pasting long text in description not placing cursor at end of text

What is the root cause of that problem?

Cursor positon is not corrected while pasting text similar to Composer text field.
The text input is neither subscribed to useHtmlPaste hook nor having a similar logic for correction of cursor while pasting from clipboard.

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

useHtmlPaste hook to be used in description text field similar to composer and notes text fields.
However, if the approach is an overkill in case certain characters are not permitted in description, we may reuse the logic from useHtmlPaste to address the issue here.

What alternative solutions did you explore? (Optional)

N.A.

[melvin-bot]

@mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[kpadmanabhan]

@mallenexpensify : I would like to work on this issue, based on previous work in this area. Please assign this to me.
Proposal.

[melvin-bot]

@mallenexpensify Still overdue 6 days?! Let's take care of this!

[melvin-bot]

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

[melvin-bot]

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

[mallenexpensify]

@mollfpr can you review @kpadmanabhan proposal above and the issues I linked above too?
#45885 (comment)

[abzokhattab]

this proposal is the same as mine ... can u please let me know your opinion about my proposal?

[mollfpr]

I agree that the @kpadmanabhan solution is the same as the @abzokhattab proposal. It seems using useHtmlPaste is fixing the issue, but can we seek a universal solution so it can fix the issue in another place?

[abzokhattab]

Updated Proposal: added an alternative solution

[kpadmanabhan]

@abzokhattab : didnt notice your proposal earlier. sorry for that.

@mollfpr : according to me useHtmlPaste itself is a universal solution as it is the central handling for all paste actions for the control passed in. We can add this by default to any text input, unless it is unsubscribed explicitly.

[melvin-bot]

@mallenexpensify @mollfpr 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!

[melvin-bot]

@mallenexpensify, @mollfpr Huh... This is 4 days overdue. Who can take care of this?

[mollfpr]

according to me useHtmlPaste itself is a universal solution as it is the central handling for all paste actions for the control passed in. We can add this by default to any text input, unless it is unsubscribed explicitly.

I mean a solution that can be fixed without applying useHtmlPaste every time we want the multiline input.

[mollfpr]

I'm not sure if bringing back the old solution is a good idea. One of the goals of our refactor was to get rid of scrolling into view by calculating pixels. We wanted to simplify it and use the new structure elements as a base for a new approach. We've missed the case when the element's content is too long, but we can definitely fix this issue by modifying the current solution.

I agree with @Skalakid 👍

@dominictb Let's try to find a solution that fits the current implementation.

[joekaufmanexpensify]

Going to try reproducing this today, as it sounds like it may no longer be reproducible?

[dominictb]

@joekaufmanexpensify this is reproducible as mentioned above.

[dominictb]

Let's try to find a solution that fits the current implementation.

@mollfpr this is tricky. I'll need to do some testing and get back on this later.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[Skalakid]

Hello, I decided to investigate this issue more inside the library since I have more capacity. To fix this issue and overall scrolling into view logic, we have to make some bigger logic changes inside the library.

First of all, we don't need to scrollIntoView on every input change or event. We can do it only on the actions that were totally replaced by our custom implementation, like: onPaste and onFocus and value prop changes. The rest of the actions can use the default browser's scroll logic. Thanks to that, Live Markdown Input works and feels more like normal RN TextInput.

After that, we can update our scrollIntoView function, so whenever the cursor isn't visible inside the input window, it scrolls to the position of the cursor range. Something like this:

 const selection = window.getSelection();
    if (selection && selection.rangeCount > 0) {
      const range = selection.getRangeAt(0);
      const caretRect = range.getBoundingClientRect();
      const targetRect = target.getBoundingClientRect();

      // In case the caret is below the visible input area, scroll to the cursor position
      if (caretRect.top + caretRect.height > targetRect.top + targetRect.height) {
        targetElement.scrollTop = caretRect.top + caretRect.height - targetRect.top - targetRect.height + target.scrollTop;
      }
    }

I will come back to you with the PR today

[Skalakid]

Here is the PR with the fix inside the react-native-live-markdown library: Expensify/react-native-live-markdown#502

[melvin-bot]

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

[mvtglobally]

Issue not reproducible during KI retests. (Third week)

[melvin-bot]

@mallenexpensify, @mollfpr 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[mallenexpensify]

@Skalakid is working on so I add them as an assignee

[melvin-bot]

@mallenexpensify, @mollfpr, @Skalakid 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[Skalakid]

Hello, the PR with the bump was reverted. Here I'm bumping the library again

[melvin-bot]

@mallenexpensify, @mollfpr, @Skalakid 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[mvtglobally]

Issue not reproducible during KI retests. (Fourth week)

[melvin-bot]

@mallenexpensify, @mollfpr, @Skalakid 12 days overdue now... This issue's end is nigh!

[melvin-bot]

This issue has not been updated in over 14 days. @mallenexpensify, @mollfpr, @Skalakid eroding to Weekly issue.

[mallenexpensify]

@Skalakid can you provide an update? Wondering if this is worth fixing, def an edge case bug that's not going to affect many/anyone.