feat: Add experimental contenteditable message composer #35975
Conversation
- Replaced the `ComposerMessageInput`'s underlying `<textarea>` with a `<div contenteditable>`. - Currently, this implementation is non-functional beyond accepting plain text input. - Placeholder support is currently not working due to limitations with `contenteditable`. - Further work is needed to restore full functionality, including keyboard event handling, Markdown formatting, and cursor management. - Clipboard paste and file attachments continue to work as expected. - Updated Storybook stories to include `MessageComposerInputNew` for preview and testing. - Refactored existing stories and exports for clarity and compatibility with the new input component.
- Cloned `CreateComposerAPI.ts` as `newCreateComposerAPI.ts` and updated references from `HTMLTextAreaElement` to `HTMLDivElement`. - Implemented `getSelectionRange` and `setSelectionRange` using the Selection API to replace `input.selectionStart` and `input.selectionEnd`. - Fixed Enter key functionality, allowing messages to be sent as expected. - Restored Bold, Italics, and Strikethrough button functionality, confirming successful Selection API migration. Known Issues & Next Steps - Enabled `/` key to trigger the slash command menu, but pressing Enter currently inserts the command and sends the message immediately. - Emoji autocomplete works, but pressing Enter finalizes the emoji and sends the message. - **The Send button remains visually disabled**, requiring an additional fix to update its state. - Next step: Prevent message sending when popups (slash command, emoji autocomplete) are active.
- Updated reducer function to handle FormEvent<HTMLDivElement> instead of FormEvent<HTMLInputElement>. - Changed event target from HTMLInputElement to HTMLDivElement for compatibility with contenteditable. - Used `innerText.trim()` instead of `value.trim()` to correctly determine if the message input is empty. - Replaced `onChange` with `onInput` in `MessageComposerInputNew` to properly detect user input. This ensures the Send button is correctly enabled or disabled based on input presence. Known Issues & Next Steps: - Pressing `/` opens the slash command menu, but pressing Enter inserts the command and sends the message immediately. - Emoji autocomplete works, but Enter finalizes the emoji and sends the message. - Next step: Prevent message sending when popups (slash command or emoji autocomplete) are active.
- Introduced `featurePreviewComposer` flag to toggle between the new <div contenteditable> input and the classic <textarea> input. - Conditionally render `MessageBoxNew` or `MessageBox` based on the flag. - Added `MessageComposerHint` in `MessageBoxNew` to label the feature as experimental.
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
|
MartinSchoeler
requested review from
MartinSchoeler
and removed request for
a team
There was a problem hiding this comment.
I know this is just the initial version of code, but there some anomaly that I found that might can help, when you make a text bold and then you remove the astrisk around it , still show the text in bold in text editor and also there is some issue with the autogrow (I know its commented) but when the input size increase there is some error with the toolbox.
packages/ui-composer/src/MessageComposer/MessageComposerInputNew.tsx
Outdated
Show resolved
Hide resolved
apps/meteor/client/views/room/composer/messageBox/MessageBoxNew.tsx
Outdated
Show resolved
Hide resolved
- Changed class name from `rc-message-box__textarea` to `rc-message-box__divcontenteditable`. - Rectified string values for `minHeight` and `maxHeight` with numeric values. - Corrected `minHeight` from `52px` to `20px` to match new layout requirements.
I tested the hotkey which is When the selection is empty, the asterisks are added. And any text within that asterisk will naturally get bolded after submitting the text. However, if you bold a text with the same shortcut, it shows an actual bold text because that is the behaviour of the So a bold text on submission does not remain bold since Rocket.Chat composer cannot see the asterisk formatters. It only sees plain text. This is a really good find. Thank you for pointing that out. The next commit will be focusing on eliminating this issue. |
| @@ -7,6 +7,7 @@ import { | |||
| MessageComposerAction, | |||
There was a problem hiding this comment.
As the MessageComposer we are creating is a different component, not a variation, I would suggest creating a new .stories.tsx file for it, let's try to modify existing files as little as possible (this way we will have less conflicts merging develop into this branch)
packages/ui-composer/src/MessageComposer/MessageComposerInputNew.tsx
Outdated
Show resolved
Hide resolved
apps/meteor/app/ui-message/client/messageBox/newCreateComposerAPI.ts
Outdated
Show resolved
Hide resolved
apps/meteor/client/views/room/composer/messageBox/MessageBoxNew.tsx
Outdated
Show resolved
Hide resolved
This refactor removes ambiguity and improves naming consistency across the message composer components. Renamed: - `MessageComposerInputNew.tsx` → `RichTextComposerInput.tsx` - `MessageBoxNew.tsx` → `RichTextMessageBox.tsx` - `newCreateComposerAPI.ts` → `createRichTextComposerAPI.ts` Updated references in: - `ComposerMessage.tsx` - `MessageComposer.stories.tsx` - `MessageComposer/index.ts`
- Moved `getSelectionRange` and `setSelectionRange` from `createRichTextComposerAPI.ts` to a new `selectionRange.ts` file. - Improves separation of concerns and allows reuse across other modules.
- Replaced `input.value` and `input.selectionEnd` with `innerText` and `getSelectionRange` - Used `setSelectionRange` to handle caret movement - Updated event targets and types from HTMLTextAreaElement to HTMLDivElement
This is a major bugfix that resolves an erratic behavior during keydown events - Added check to skip auto-focus when target is a <div contenteditable="true"> - Prevented focus tug-of-war between main and thread composers - Improved stability of typing behavior in multi-composer layouts - Resolved a critical issue where main and thread composers kept stealing focus from each other - Stabilized typing behavior in multi-composer scenarios
- Implemented a `WeakMap` to store the last cursor position per `contenteditable div` instance - Saved cursor position on `blur` event and restored it on `focus` event
This is a major bugfix that resolves an erratic behavior during Editing mode - Editing mode failed to reset due to `.innerText` collapsing multiple spaces - Caused mismatch between original message and `RichTextComposer` content - Fixed by adding `whiteSpace: 'pre-wrap'` `to RichTextComposerInput` - Ensures consistent text comparison and reliable edit cancellation - Added comment in the `RichTextComposerInput` definition to highlight the significance
- Blocked browser insertion of <b> and <i> tags - Delegated formatting to custom shortcut handler
This issue was caused due to the editor losing focus and cursor position state when clicking a Formatter button. - Added `setSelectionRange` and `focus` prior to `execCommand` call - Fixed issue where the button would append instead of replacing the selected text
- Fixed cursor moving to end of contentEditable input and regaining focus after editing reset
Draft messages were not properly stored and restored due to use of innerText, which strips formatting. - Switched to innerHTML to retain full content structure in Accounts.storageLocation.
- Added TypingState reducer to manage `isTyping` and `hidePlaceholder` flags - Adjusted placeholder visibility based on input DOM structure - Normalized content to treat `<div><br></div>` and empty input as `<br>` - Updated RichTextComposerInput to support and render `hidePlaceholder` prop - Ensured cursor is text-style inside `contenteditable` element - Prevented saving of Composer drafts when content is only `<br>`
- Replaced `_MessageComposerNew` story with `RichTextComposer` for clarity - Added `MessageComposerHint` to highlight experimental status - Passed `placeholder` and new `hidePlaceholder` prop to `RichTextComposerInput` - Updated Storybook args for enhanced prop control
- Corrected the forwarded `ref` target to match the `contentEditable div` - Ensures proper typing and `ref` behavior for editable container - Minor style cleanup for whiteSpace and cursor properties
- Applied `overflow-y: scroll` to the `contenteditable div` for consistent scrollbar visibility - Styled `::-webkit-scrollbar-thumb` to fix invisible scrollbar in Chromium browsers
Proposed changes
This PR introduces an experimental real-time message composer powered by a
<div contenteditable>instead of the classic<textarea>. The goal is to enable richer in-place text formatting and interaction using modern DOM APIs, while maintaining compatibility with the current composer functionality.Key changes include:
<textarea>input with a<div contenteditable>inMessageComposerInputNew.onInput,innerText.trim()) to support correct state management (e.g., Send button enable/disable).featurePreviewComposerto toggle between the new input and the current one safely.MessageComposerHint) to indicate this is a preview feature.Steps to test
Set the
featurePreviewComposerflag totrue(orfalse) inapps/meteor/client/views/room/composer/ComposerMessage.tsxKnown Issues & Next Steps
/and emoji autocomplete open as expected, but pressing Enter inserts the selection and also sends the message, which is unintended.<div contenteditable>.Additional work is needed to: