[Android] Inline styles are stripped from previously-styled text when toggling a style OFF mid-word with predictive text enabled

[woosanggyu]

Description

On Android, when predictive text / word suggestions are enabled on the soft keyboard (so the current word is held in an active IME composing region), toggling an inline style (bold / italic / underline / strikethrough) OFF and then continuing to type without a space causes the previously styled text in the same composing word to lose its style.

The style formatting bit is dropped, not just the visual rendering — the earlier characters that were styled become unstyled.

Steps to reproduce

Using the library's example app (raw <EnrichedTextInput>, no wrapper):

1. Use a soft keyboard with predictive text / suggestions ON (e.g. Gboard default).
2. Focus the editor and start typing a word, e.g. abc.
3. Toggle bold ON, continue typing without a space → def (now def is bold, still one composing word abcdef).
4. Toggle bold OFF, continue typing without a space → ghi.
5. Observe the result.

Expected: def stays bold; only ghi is unstyled → abc + def + ghi.

Actual: the previously bolded def loses its bold → the whole word renders unstyled.

Notes:

• Reproduces the same way for italic / underline / strikethrough.
• The trigger is the active composing region: with predictive text OFF (or when each key is committed immediately, e.g. a hardware keyboard / emulator with hw.keyboard=yes), the bug does not occur.
• Typing a space (which commits the composing region) before toggling avoids it.

Environment

• react-native-enriched-html: reproduced on latest main (cloned repo example app) and on 1.1.0-nightly-20260724-982c0ca15.
• React Native: 0.86
• Platform: Android only (iOS unaffected).
• Reproduced on multiple environments, all with Gboard predictive text / suggestions ON:
  • Samsung Galaxy S9 — Android 10
  • Samsung Galaxy S20 Ultra — Android 13
  • Emulator: Pixel 8a, API 36 (Android 16), soft keyboard (hw.keyboard=no)

Likely cause (hypothesis)

While an IME composing region is active over the text, applying/removing an inline style span interacts with the composing region such that when the composing text is subsequently replaced (setComposingText → SpannableStringBuilder.replace), the character-level style spans within the replaced range are dropped.

Possible directions:

• Commit the composing region (InputConnection.finishComposingText()) before applying/removing an inline-style span, so the style is applied to committed (non-composing) text.
• Or re-apply / preserve existing character-level style spans across the composing-text replacement (span flags / re-span after setComposingText).

IMG_2597.MOV