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

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 covering the styled text. If the IME commits each key immediately (composing=[-1,-1]), the bug does not occur. hw.keyboard turned out not to be the determining factor.
• 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:
  • Samsung Galaxy S9 — Android 10, Samsung Keyboard, English
  • Samsung Galaxy S20 Ultra — Android 13, Samsung Keyboard, English
  • Emulator: Pixel 8a, API 36 (Android 16), Microsoft SwiftKey, English

Correction (2026-08-03). This section originally said "Gboard predictive text / suggestions ON" for all three environments. That was wrong: Gboard is not installed on the Galaxy devices, which use Samsung Keyboard. With Gboard in English the bug does not reproduce at all — Gboard sends every character via commitText with no composing region. It reproduces with any IME that keeps an active composing region, e.g. Microsoft SwiftKey on a plain emulator. See the analysis in the comments below.

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).