[$250] mWeb - Compose box - Text is not displayed in compose box after using FAB emoji with markdown

[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: v3.9.32-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-7801/folder/13176723/41237068/1233303581
Email or phone of affected tester (no customers): rogerjesusrosarioh+54@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: mWeb / iPhone 12 mini / iOS 26.3
App Component: Other

Action Performed:

1. Open any chat
2. Type "*bold " in the compose box
3. Tap on the emoji picker and select the FAB emoji
4. Continue typing in the compose box

Expected Result:

Text should be displayed in the compose box after adding the FAB emoji.

Actual Result:

Text appears in blank after adding the FAB emoji with markdown text previously added.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @shubham1206agra

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022030016527648565538
• Upwork Job ID: 2030016527648565538
• Last Price Increase: 2026-03-06

[melvin-bot]

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

[MelvinBot]

Proposal

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

On iOS mWeb Safari, when a user types partial markdown (e.g., *bold ) in the compose box, then opens the emoji picker and selects an emoji, the text in the compose box appears blank/invisible afterward.

What is the root cause of that problem?

The root cause is a race condition between the disabled prop and the value prop on the Composer component during emoji insertion on iOS Safari, compounded by Safari's contentEditable rendering behavior.

Here is the sequence of events:

1. While the emoji picker is open, the composer is disabled via disabled={isBlockedFromConcierge || isEmojiPickerVisible()} at ReportActionCompose.tsx:614. This sets contentEditable=false on the underlying MarkdownTextInput div.

2. When the user selects an emoji, EmojiPicker.selectEmoji (EmojiPicker.tsx:185-196) calls hideEmojiPicker(false) (a state update via setIsEmojiPickerVisible(false)) and then immediately calls onEmojiSelected(emoji).

3. onEmojiSelected is wired to composerRef.current.replaceSelectionWithText(...) at ReportActionCompose.tsx:657, which calls updateComment → setValue(newText) in ComposerWithSuggestions.tsx:500-507.

4. React batches these state updates. The isEmojiPickerVisible() function reads from a ref (emojiPickerRef.current.isEmojiPickerVisible) that is updated via useImperativeHandle — which only commits during the layout effects phase, AFTER the render phase. So when ReportActionCompose renders in the batched update, it reads the old ref value (true), passing disabled=true to the Composer even though the picker state has changed.

5. The parseAndStyleValue useLayoutEffect in MarkdownTextInput.web.tsx:720-738 fires because the value prop changed. It rebuilds the entire DOM via innerHTML replacement while the div's contentEditable is still false.

6. On iOS Safari, replacing innerHTML on a non-contentEditable element and then toggling contentEditable back to true in a subsequent render can cause the browser to not repaint the content. The text exists in the DOM but is not visually rendered — it appears blank.

Additionally, the cursor position update is silently dropped because setCursorPosition in cursorUtils.ts:6-10 returns early when target !== document.activeElement (the composer isn't focused since the emoji picker was just open). This means even after the composer regains focus, the cursor may be in an unexpected position.

The partial markdown (*bold ) makes this more likely to manifest because the parser produces a more complex DOM structure (multiple spans for text + emoji) compared to plain text, increasing the chance of triggering Safari's contentEditable rendering bug.

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

Option A (Recommended): Remove isEmojiPickerVisible() from the disabled prop in ReportActionCompose.tsx:614. Instead of disabling the entire composer while the emoji picker is open, prevent keyboard input through other means (the keyboard is already dismissed when the picker opens via KeyboardUtils.dismissKeyboardAndExecute in EmojiPickerButton.tsx:55). This avoids the contentEditable toggling entirely:

// ReportActionCompose.tsx:614
// Before:
disabled={isBlockedFromConcierge || isEmojiPickerVisible()}
// After:
disabled={isBlockedFromConcierge}

Option B (if Option A causes regressions): Add a Safari-specific workaround in MarkdownTextInput.web.tsx that forces a repaint after contentEditable transitions from false to true. This could be done by adding a useEffect that watches the disabled prop and triggers a re-parse when it transitions from true to false:

// In MarkdownTextInput.web.tsx, after the parseAndStyleValue effect
useEffect(() => {
  if (!disabled && divRef.current && divRef.current.value) {
    // Force re-parse when becoming editable to fix Safari repaint issue
    parseText(parser, divRef.current, divRef.current.value, processedMarkdownStyle, null, true, false, false);
  }
}, [disabled]);

What alternative solutions did you explore? (Optional)

1. Deferring emoji insertion until onModalHide: Moving the onEmojiSelected callback to fire only after the modal fully hides would avoid the race condition but would introduce a noticeable delay between selecting an emoji and seeing it appear.

2. Extending shouldUseEmojiPickerSelection to iOS Safari: Currently this workaround only covers Android and Chrome mobile (shouldUseEmojiPickerSelection/index.ts). Adding iOS Safari support might help with cursor positioning but wouldn't fix the underlying contentEditable repaint issue.

3. Using requestAnimationFrame in parseAndStyleValue: Deferring the DOM rebuild to the next animation frame could help Safari process the contentEditable transition first, but this would introduce flickering as the old content would briefly show before being replaced.

Detailed Investigation

Evidence Chain

1. Composer disabled during emoji picker: ReportActionCompose.tsx:614 passes disabled={isBlockedFromConcierge || isEmojiPickerVisible()} to the Composer
2. Emoji insertion happens before picker fully closes: EmojiPicker.selectEmoji calls hideEmojiPicker(false) then onEmojiSelected synchronously — the state update hasn't committed when the insertion starts
3. DOM rebuilt while contentEditable=false: parseAndStyleValue useLayoutEffect at MarkdownTextInput.web.tsx:720-738 runs with isFocused=true (hardcoded) but the actual DOM element isn't focused and has contentEditable=false
4. Cursor update silently dropped: setCursorPosition at cursorUtils.ts:8 returns early when target !== document.activeElement
5. iOS Safari contentEditable quirk: Safari is known to have rendering issues when innerHTML is replaced on elements transitioning between contentEditable states

Relevant Code

• ReportActionCompose.tsx:614 — disabled prop with isEmojiPickerVisible()
• EmojiPicker.tsx:185-196 — selectEmoji calling hide then insert
• ComposerWithSuggestions.tsx:500-507 — replaceSelectionWithText
• MarkdownTextInput.web.tsx:720-738 — parseAndStyleValue effect
• MarkdownTextInput.web.tsx:271-276 — updateTextColor
• cursorUtils.ts:6-10 — setCursorPosition focus guard
• EmojiPickerAction.ts:95-101 — isEmojiPickerVisible reading ref
• shouldUseEmojiPickerSelection/index.ts — iOS returns false (no workaround)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[djblack1209-coder]

Proposal

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

When a user types partial markdown like *bold in the composer, then inserts the FAB emoji from the emoji picker, the composer looks blank when they continue typing on iOS mWeb Safari.

What is the root cause of that problem?

The FAB emoji insertion path does not restore the composer selection/caret after the emoji picker closes.

That matters here because the composer is using the live-markdown input path. With partial markdown, iOS Safari is more sensitive to blur/refocus and selection loss. After the picker closes, the text input regains focus, but the caret/selection is no longer restored to a valid visible position, so the next typed characters go into the wrong DOM range and the text appears blank.

This is different from the emoji suggestion path, which already updates the selection after insertion.

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

1. Update the FAB emoji insertion flow to behave like the emoji suggestion flow.
2. After inserting the emoji, explicitly restore the composer selection to the position right after the inserted emoji.
3. Keep the selection restoration after the emoji picker closes on mWeb/Safari so continuing to type stays in the visible live-markdown range.
4. Add a regression test for: partial markdown -> FAB emoji insert -> continue typing.

What alternative solutions did you explore? (Optional)

I also considered only forcing focus() after the picker closes, but that would not be enough because the bug is caused by losing the correct selection/caret, not just losing focus.

[melvin-bot]

📣 @djblack1209-coder! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[djblack1209-coder]

Contributor details
Your Expensify account email: djblack1209@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01c405eb228694d96b