Windows emoji composition can fail when textarea autocorrect is disabled

Summary

On Windows, the emoji panel (Win + .) can fail to insert emoji into the editor textarea when the internal textarea has autoCorrect="off".

The emoji panel opens, but selecting an emoji does not dispatch composition/input events to the editor textarea in the failing case. Overriding the textarea to autoCorrect="on" fixes the issue in the same editor and content.

Environment

• Package: @uiw/react-md-editor
• Observed version: 4.0.11
• Browser: Chromium-based browser on Windows
• OS input: Windows emoji panel via Win + .
• Content size in repro: long markdown body, around 13k characters

Current upstream source still sets these defaults on the internal textarea:

<textarea
  autoComplete="off"
  autoCorrect="off"
  autoCapitalize="off"
  spellCheck={false}
  {...other}
/>

Reproduction

1. Render an editor with a long markdown value.

<MDEditor
  value={longMarkdown}
  onChange={setValue}
  preview="live"
/>

2. Focus the editor textarea somewhere in the long body.
3. Press Win + . on Windows.
4. Select an emoji from the Windows emoji panel.

Actual behavior

The emoji panel opens, but the selected emoji is not inserted into the editor textarea.

In event tracing, the editor textarea only receives the key events around opening the panel, for example keydown Meta / keyup Period. After selecting an emoji, no compositionstart, beforeinput, or input event reaches the textarea.

Expected behavior

Selecting an emoji from the Windows emoji panel should insert the emoji into the editor textarea and dispatch the normal composition/input events.

Debugging notes

The issue appears tied specifically to autoCorrect="off" on the textarea:

• A native textarea with the same long value accepts emoji input correctly.
• A cloned textarea outside the editor tree also accepts emoji input correctly.
• The actual editor textarea starts accepting emoji immediately when autocorrect is changed to on at runtime.
• Changing only spellcheck, autocomplete, or autocapitalize did not fix the issue in my test.

Workaround

Passing autoCorrect: "on" through textareaProps fixes the issue downstream:

<MDEditor
  value={value}
  onChange={setValue}
  textareaProps={{
    autoCorrect: "on",
  }}
/>

Possible fix

Consider not forcing autoCorrect="off" by default, or documenting this Windows emoji-panel interaction and the textareaProps.autoCorrect = "on" workaround.

Start at the MDEditor entry point and inspect the internal textarea defaults, especially autoCorrect and how textareaProps are applied. Reproduce the Windows emoji-panel case with the long markdown example, then verify that selecting an emoji inserts it and dispatches the expected composition/input events without breaking the existing textarea behavior.