[$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
• [x] Android: mWeb Chrome
• [ ] iOS: Native
• [x] iOS: mWeb Safari
• [ ] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

https://github.com/user-attachments/assets/5a995426-49ea-4adc-ae42-a15bccdc1c97

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

[mollfpr]

Not overdue, still open for proposals!

[dominictb]

Edited by proposal-police: This proposal was edited at 2024-09-11 07:51:41 UTC.

Proposal

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

Reproduction step:

• Open a room description modal
• Try to paste a long paragraph (long enough to make the text box scrollable) inside in the text box -> The cursor is not scrolled into view

https://github.com/user-attachments/assets/e915e32c-affb-482a-addc-46e14598b93f

What is the root cause of that problem?

The new RN live markdown implements a new scrollIntoView function. This implementation will scroll element (which could be <span>, <p>,... that contains the cursor into view. However, this won't work in case the text inside <span> element is long enough to cover the bound height of the input (check the image below)

And in this case, only the beginning of the paragraph (the span element) is scrolled into view, but not the cursor.

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

We can bring this implementation from 0.1.116.

function scrollIntoView(target: MarkdownTextInputElement, node: TreeNode) {
  if (node.type === 'br' && node.parentNode?.parentNode?.type === 'line') {
    // If the node is a line break, scroll to the parent paragraph, because Safari doesn't support scrollIntoView on br elements
    node.parentNode.parentNode.element.scrollIntoView({
      block: 'nearest',
    });
  } else {
    // brought the old implementation here
    if (BrowserUtils.isFirefox) {
      // In the old implementation we don't support scroll the cursor into view in Firefox, so in here we can simply call `scrollIntoView` (which is the new implementation)
      node.element.scrollIntoView({
        block: 'nearest',
      });
      return;
    }
    // old implementation: Calculate the cursor position and force the input to scroll to the exact coordinates
    const selection = window.getSelection();
    if (!selection || selection.rangeCount === 0) {
      return;
    }
    const caretRects = selection.getRangeAt(0).getClientRects();

    // we'll find the caretRect from the DOMRectList above with the largest bottom value
    let currentCaretRect = caretRects[0];
    if (currentCaretRect) {
      for (let i = 1; i < caretRects.length; i++) {
        const caretRect = caretRects[i];
        if (caretRect && caretRect.bottom > currentCaretRect.bottom) {
          currentCaretRect = caretRect;
        }
      }
    }

    const editableRect = target.getBoundingClientRect();

    // Adjust for padding and border
    const paddingTop = parseFloat(window.getComputedStyle(target).paddingTop);
    const borderTop = parseFloat(window.getComputedStyle(target).borderTopWidth);

    if (currentCaretRect && !(currentCaretRect.top >= editableRect.top + paddingTop + borderTop && currentCaretRect.bottom <= editableRect.bottom - 2 * (paddingTop - borderTop))) {
      const topToCaret = currentCaretRect.top - editableRect.top;
      const inputHeight = editableRect.height;
      // Chrome Rects don't include padding & border, so we're adding them manually
      const inputOffset = currentCaretRect.height - inputHeight + paddingTop + borderTop + (BrowserUtils.isChromium ? 0 : 4 * (paddingTop + borderTop));

      target.scrollTo(0, topToCaret + target.scrollTop + inputOffset);
    }
  }
}

What alternative solutions did you explore? (Optional)

[mallenexpensify]

@mollfpr , plz review @dominictb 's proposal above, thx

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot[bot]]

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

[mallenexpensify]

@mollfpr and @dominictb , regarding the post from QA not being able to reproduce, can you both attempt reproduction and share your results? If you're able to, please provide vid or screenshots.

[dominictb]

Proposal updated to add reproduction steps and video.

[mollfpr]

I am still able to reproduce the issue, it's only reproducible with long text paragraphs and doesn't have a break-line space at the end of the paragraph. The same things happen for Safari.

https://github.com/user-attachments/assets/fb21d21f-a34d-4060-a392-7f744321ce36

@dominictb Is there a reason we using scrollIntoView from the element interface and replacing our own logic?

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[mallenexpensify]

@joekaufmanexpensify I'm out til Tuesday, can you keep 👀 on plz? Thx

[dominictb]

https://github.com/Expensify/App/issues/45885#issuecomment-2343744710

@mollfpr I don't have the answer for that, my guess is because they miss the test case when they try to refactor the markdown library.

@BartoszGrajdek @Skalakid loop in you guys for second opinion.

[Skalakid]

@dominictb 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. My idea is to detect if the cursor is outside the view and just launch node.element.scrollIntoView(false) or node. element.scrollIntoView({block: "bottom"}) to scroll to it

[dominictb]

@Skalakid your idea doesn't work in this test case:

• Copy/Paste the long paragraph in a max-height input
• Go to the beginning of the input
• Paste the same paragraph

-> Now it scrolls down to the bottom due to the fact that the startTreeNode is now a large <span>, but the cursor appears in the middle (and out of view).

https://github.com/user-attachments/assets/37641b77-1ac1-4c7e-9f3d-aeb01025163d

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[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[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: https://github.com/Expensify/react-native-live-markdown/pull/502

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

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

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

[Skalakid]

Hello, the PR with the fix has been merged so the issue should be fixed now

[mollfpr]

@mallenexpensify I can't repro the issue anymore. I think we can close this.

[mallenexpensify]

Thanks @mollfpr , closing. Comment/reopen if anyone disagrees.