Chainlit 2.6.0 - Pasting Content Has Several Additional Issues After Newlines Fix

[AidanShipperley]

Describe the bug

The latest Chainlit 2.6.0 release had a PR to fix input spacing issues (#2246), which attempted to address newline issues by switching from insertHTML to insertText with HTML escaping, but this created a cascade of new problems (see below). This is the fourth major issue (#1890, #2032, #2087) with input handling in the main message composer since v2.0.5 introduced inline commands, which at the time mimicked how ChatGPT rendered commands in their UI as in line with the text at the beginning of the composed message.

When we look at the Edit Message Composer in the UserMessage.tsx file, which has had no issues dealing with pasting content at all, we can see it is using AutoResizeTextarea - which is essentially a <textarea> element.

The Main Message Composer (Input.tsx), however, uses a contentEditable div with tons of custom logic for handling escaping html elements, handling pasted content properly, allowing undoing/redoing properly, spacing, etc.

The use of contentEditable is solely to support rendering the name of the user's selected command in line with the text - a feature that ChatGPT does not even use anymore. There have been continual issues in each release since v2.0.5 that significantly impact the ability for users to use Chainlit across different platforms for editing and understanding content pasted by them. It seems reasonable at this point for Chainlit to adopt an approach for commands similar to what ChatGPT does today (using buttons in combination with a toolbox under the chat input) as properly working with contentEditable across all browsers and for all content will explode the complexity of the Input.tsx file and it seems unreasonable to expect the code to handle all possible edge cases perfectly.

I will do my best to work on a PR that stops rendering the selected command inline without breaking backwards compatibility or worsening the user experience, but if there is some easy solution I missed, please feel free to let me know.

---

 
Below are the newly introduced issues in 2.6.0:

To Reproduce

Issue 1: HTML entities shown in composer

When pasting code containing <> or quotes, they appear as <> and ' in the composer, making it impossible to edit pasted code.

Example:

-- Pasted:
WHERE DEF <> ''

-- Shows in composer as:
WHERE DEF &lt;&gt; &#039;&#039;

Issue 2: Multiple consecutive newlines in pasted content are invisible in the composer, though they render correctly after sending

Given the following code snippet:

print("Line 1")

print("Line 3")


print("Line 6")

When pasted into the message composer, all lines are rendered right next to each other, like so:

print("Line 1")
print("Line 3")
print("Line 6")

You can also see issue 1 at work here.

Issue 3: Undo/redo broken

Undo and Redo after pasting content is now broken again, an issue previously broken and addressed.

---

These are just a few obvious ones I found after testing. There are several other minor issues and discrepancies with user pasted content that were not present pre-v2.0.5, when we were not using commands.

Expected behavior

Chainlit should be able to match the content pasted into it, and render user content consistently with what the user sent.

Desktop

• OS: Windows 11
• Browser: Microsoft Edge
• Version: 137.0.3296.93 (Official build) (64-bit)

[dosubot]

The issues you’re seeing stem from the complexity of using a contentEditable div in the main message composer to support inline command rendering. The recent change to use insertText with HTML escaping causes pasted code to show HTML entities like <> and ', and also breaks newlines and undo/redo, because the custom paste handler escapes everything and inserts it as plain text, losing formatting and native browser behaviors. The edit composer, which uses a simple textarea, doesn’t have these problems because the browser handles pasted content, newlines, and undo/redo natively see code analysis see edit composer.

This pattern of regressions has come up in multiple versions since inline commands were introduced, and there’s no evidence of a simple fix that doesn’t involve either a major refactor or dropping inline command rendering see prior issues. If you want to avoid these edge cases, moving away from inline commands (like ChatGPT’s current approach) and using a textarea or similar native input is the most robust solution. If you need to keep the current UI, you’d need to rework the paste handler to avoid escaping HTML entities on paste and handle newlines more carefully, but this is tricky and likely to introduce more edge cases.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[rajanarahul93]

Hi @AidanShipperley , I’ve created a PR to address this issue. Would love your review and feedback when you have a moment. Thanks!

[AidanShipperley]

Hi @AidanShipperley , I’ve created a PR to address this issue. Would love your review and feedback when you have a moment. Thanks!

Hi @rajanarahul93, thank you for taking the time to try and work out a solution!

The PR unfortunately wasn't able to resolve all of the issues. I put a comment on the PR with some context.

I mention this in the PR comment, but with the combination of needing execCommand to preserve undoing/redoing and the fact that ChatGPT does not render inline commands anymore, I still think the best approach long-term for this is to move away from inline command rendering altogether, as this would completely prevent the need for countless iterations on the same code to fix all possible edge cases.

I will still work on a PR fix that aims to do this, but if you do manage to address all issues without removing inline commands I think that would be a great immediate fix.

[rajanarahul93]

Yeah, sounds good. I’ll make the changes you suggested.

[aharth]

Not sure if #1930 is related, but it would be really nice if the UI properly handles colons.

Test case: try pasting foo:bar is a CURIE.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.