[Due for payment 2025-06-03] [$250] mWeb- Compose box - The first and second line text merge together in compose box

[jponikarchuk]

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: v9.1.29-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5952175
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Device used: Samsung Galaxy s10/ Android 12
App Component: Chat Report View

Action Performed:

1. Navigate to any conversation in mweb
2. Send a message with multiple line breaks
3. Copy the message with multiple line breaks
4. Paste the text in the compose box from clipboard (IMPORTANT)
5. Send the message

Expected Result:

The text should displayed correctly in the conversation history with the line breaks preserved.

Actual Result:

The first and second line text merge together.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021914951555967684695
• Upwork Job ID: 1914951555967684695
• Last Price Increase: 2025-05-14
• Automatic offers:
• allgandalf | Reviewer | 107482168

Issue Owner

Current Issue Owner: @allgandalf

[melvin-bot]

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

[Eskalifer1]

Proposal

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

mWeb- Compose box - The first and second line text merge together in compose box

What is the root cause of that problem?

The issue stems from how Gboard (Google Keyboard) handles multi-line clipboard pasting on Android devices. Unlike traditional paste operations that trigger a paste or insertFromPaste event, Gboard inserts the entire multi-line content via an insertText input event — treating it as if the user typed the text manually.

As a result:

The ClipboardEvent listener (onPaste) never fires.

The inserted text includes \n characters (line breaks), but when inserted into a contenteditable element, the browser may silently discard the first newline or improperly merge lines, especially when the initial content is empty.

Importantly, this bug only occurs when the text input is completely empty. If there's already any content in the field (even a single character), pasting works correctly — all newlines are preserved.

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

We already have a hook, and it is used to set the text:

App/src/hooks/useHtmlPaste/index.ts

Line 40 in 92707c3

const useHtmlPaste: UseHtmlPaste = (textInputRef, preHtmlPasteCallback, isActive = false, maxLength = CONST.MAX_COMMENT_LENGTH + 1) => {

Enhance useHtmlPaste or related composer logic with a beforeinput listener:

Add a beforeinput event listener only when the composer is active, to detect Gboard-style paste behaviors (i.e., insertText events with newline characters on empty input).

useEffect(() => {
        if (!isActive) {
            return;
        }

        const textInputElement = textInputRef.current as HTMLElement;
        if (!textInputElement) {
            return;
        }

        const handleInput = (event: InputEvent) => {
            if (event.inputType === 'insertFromPaste' || event.inputType === 'insertText') {
                const inserted = event.data ?? '';

                if (inserted.includes('\n') && (textInputElement.textContent ?? '') === '') {
                    event.preventDefault?.();
                    insertAtCaret(textInputElement, inserted, maxLength);
                }
            }
        };

        textInputElement.addEventListener('beforeinput', handleInput);
        return () => {
            textInputElement.removeEventListener('beforeinput', handleInput);
        };
    }, [isActive, textInputRef, maxLength]);

The new handler only enhances Android+Gboard behavior and does not interfere with regular paste flows (like CMD+V, Ctrl+V, or long-press paste on other platforms).

Optional: We can add verification to the Android platform and to the Web. But I don't know if this is necessary, because I was able to reproduce it only on an real Android device

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[bernhardoj]

Proposal

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

The first new line is removed when placing the copied text into composer.

What is the root cause of that problem?

This is an issue with the live markdown component. When we "paste" the text from the android keyboard, it will trigger onChangeText. parseInnerHTMLToText will parse the composer HTML into text.
https://github.com/Expensify/react-native-live-markdown/blob/066f5f9421cf5a3faaf96aa75c4328ac569ee2fd/src/web/utils/inputUtils.ts#L66-L80

If we copy and "paste" into an empty composer,

test1
test2
test3

the composer HTML is

<div contentEditable="true" ...>
    test1
    <div>test2</div>
    <div>test3</div>
</div>

parseInnerHTMLToText will then add a new line to each top component, a component that is a direct child of the div contentEditable, but it ignores a text node.

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

I think we need the SWM help to better understand why we skip the text node, but for now, my suggestion is to also include a newline for the text node by removing the if else. (code, same linked code as above)

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

[melvin-bot]

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

[melvin-bot]

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

[JmillsExpensify]

Opened up to the community