[$250] Tasks - Pressing enter key after a mark down doesn't show the new line

[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.13-3
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Click on the Green plus Icon
3. Click on Assign task
4. Insert a sample title
5. Click on Description
6. Insert multiple-line text until a scroll bar is shown on the right
7. On a new line insert a markdown text (eg. bold)
8. Hit the enter key on the keyboard
9. For comparison on a new line insert a normal text (e.g text)
10. Hit the enter key on the keyboard

Expected Result:

When hitting the enter key after a mark down the new line becomes visible with the cursor seen visibly

Actual Result:

When hitting the enter key after a mark down the cursor gets hidden on the new line which is a different behavior when compared with the behavior seen on a normal text and hitting enter key

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

Bug6550710_1721751760580.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019aa27e395e6f5aae
• Upwork Job ID: 1819367536186479442
• Last Price Increase: 2024-08-16
• Automatic offers:
• dominictb | Contributor | 103558387

[melvin-bot]

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

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

[lanitochka17]

We think that this bug might be related to #Live Markdown

[dominictb]

Proposal

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

When hitting the enter key after a complex markdown element (bold, italic, quote, hashtag,...) the input doesn't scroll down to the new line at the bottom, unlike when hitting entering key after a plain text in the input.

What is the root cause of that problem?

When we hit the Enter key or change the text, the cursor will be moved around and this function will scroll the cursor into view. scrollCursorIntoView function above is called in here and here

Considering 2 following scenarios:

Hitting Enter after plain text

In this case the whole text node would look like 1\n\n and because 1 is a plain text, i.e there's no HTML tag like span, div wrapping around the text content, the last text node in the HTML content is \n (the final newline character), and the caret will be placed before that. We can easily verify by adding console.log(selection.getRangeAt(0)) here

Hitting enter key after a complex markdown element, e.g: bold, italic, quote, hashtag,...

Same reasoning as the first scenario, but now since the previous node is an element node, somehow the browser will join the newline after that to the last text node, and place the caret between 2 newlines. Simply put, the HTML value would look like

<span>#something</span>\n<text-caret-here>\n

We can verify by adding console.log(selection.getRangeAt(0)) here, and we can easily see that the offset of the selection range is now 1, not 0

So, because the selection range which represents caret is different in 2 scenarios, hence selection.getRangeAt(0).getClientRects here will return 2 different DOMRectList

• In the first scenario, the DOMRectList contains 1 DOMRect because the last text node only contains 1 single \n character

• In the second scenario, the DOMRectList contains 2 DOMRects because the last text node contains 2 \n characters (and the caret is placed between them)

And we only use the first DOMRect to calculate the scroll offset, but in the second scenario, the DOMRect is still positioned in the previous line, not the latest new line hence this condition holds true, and there's no scrolling

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

In case the DOMRect list of selection.getRange(0).getClientRects() returns more than 1 value, we should select the last DOMRect, or the DOMRect that maximizes the chance of this condition being false.

const caretRects = selection.getRangeAt(0).getClientRects();
 const caretRect = caretRects[caretRects.length-1] // or we can select the `DOMRect` with max `bottom` value. During testing this seems enough to make this work.

What alternative solutions did you explore? (Optional)

[johncschuster]

This will either fit under #live-markdown or #tasks. I think it's live markdown related.

[BartoszGrajdek]

Hi, I'm Bartosz from SWM react-native-live-markdown team! This issue is in fact live markdown related, thanks for adding it to the project 🙌🏻

I'm going to be OOO till 11.08, so I'm tagging @tomekzaw here for visibility.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[johncschuster]

Not overdue. We're waiting on @BartoszGrajdek to come back from OOO.

[johncschuster]

Bumping to keep Melvin happy

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

@johncschuster @Pujan92 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]

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

[johncschuster]

Bumping this one. Were you able to pick this back up, @BartoszGrajdek?

[dominictb]

Hmm for live markdown related issue, shall we wait for the live markdown team to review the proposal, or C+ can also review?

[BartoszGrajdek]

Bumping this one. Were you able to pick this back up, @BartoszGrajdek?

Thanks for the bump @johncschuster ! We had quite a few high-priority issues this week. 😅 @dominictb's proposal makes sense to me, so if you agree, we can assign him to this issue. He can then raise a PR to react-native-live-markdown, and we can test it there. 🙌🏻

Unfortunately, our team at SWM will be OOO on Thursday and Friday due to a public holiday (sorry about that again 🙏🏻).

In the meantime, you or any C+ member can review the PR in our repo. Just please hold off on merging it, as we’d like to test it against some of our known regressions once we're back to ensure we don't break anything. 👀

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

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

[johncschuster]

Sounds great, @BartoszGrajdek! Thanks for that update!

@dominictb, I've assigned the issue to you. Please review @BartoszGrajdek's comment above

[dominictb]

PR Expensify/react-native-live-markdown#454 is ready.

[dominictb]

@Pujan92 @johncschuster @BartoszGrajdek app PR #47763 is ready for review.

[dominictb]

@BartoszGrajdek @Skalakid it seems like in the latest main, I couldn't put a new line by pressing Enter or Shift+Enter, so I couldn't test further

Screen.Recording.2024-08-28.at.15.09.06.mov

[dominictb]

@johncschuster I have closed the app PR since we have another PR that bump to markdown lib to 0.1.117 (#47763), however we'll still need to test on latest main to see if this issue is fixed

cc @Pujan92

[dominictb]

@johncschuster @Pujan92 this is fixed on latest main, and since we had the production deployment recently, can we confirm that this is ready for payment?

[johncschuster]

Payment Summary:

Contributor: @dominictb paid $250 via Upwork - PAID! 🎉
Contributor+: @BartoszGrajdek does not require payment

[johncschuster]

Does this require regression test steps? If so, can you please post them?

[Pujan92]

@johncschuster I haven't reviewed the proposal or markdown PR for this issue so no payment for me. All done by @BartoszGrajdek. Thanks to them!

[johncschuster]

Got it. Thanks, @Pujan92! @BartoszGrajdek / @dominictb do you feel we need some regression steps for this one?

[johncschuster]

Bumped in Slack for regression test steps

[dominictb]

Regression test steps:

1. Go to NewDot app and create a new task using QAB
2. Click on Description
3. Insert multiple-line text until a scroll bar is shown on the right
4. On a new line insert a markdown-format text, e.g: bold, italic, #room-mention,...
5. Hit the enter key on the keyboard

Verify that: When hitting the enter key, the new line becomes visible with the cursor seen visibly.

[johncschuster]

Thank you!