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

IMG_2597.MOV

[kacperzolkiewski]

Hi @woosanggyu,

I tried to reproduce the issue on both an Android emulator and a physical device, but I couldn't reproduce it.
Are you performing any additional steps before it happens?

Screen.Recording.2026-08-03.at.10.38.56.mov

[woosanggyu]

Sorry for the confusion — I only ever tested on Samsung Galaxy devices, and that
skewed the report.

The trigger isn't the device, it's the keyboard: the bug needs an active IME
composing region over the styled text. Samsung Keyboard keeps one; Gboard in
English does not — it sends every character via commitText, so this code path
is never entered and nothing can break. That's almost certainly why you couldn't
reproduce it.

To reproduce on an emulator or any non-Samsung device, install Microsoft SwiftKey from the Play Store,
set it as the active keyboard, and run the same
steps: type abc, tap B, type ghi, tap B, type q. Bold is lost from
ghi, and Show HTML returns <p>Abcghiq</p> with no <b>.

SwiftKey isn't an exotic pick here — the library already supports it explicitly:
EnrichedTextInputConnectionWrapper.sendKeyEvent carries a branch written for
SwiftKey's behaviour ("Called by SwiftKey when cursor at beginning of input when
there is a delete...").

I've verified #737 fixes it on both setups. Happy to share the InputConnection
logs if useful.

2026-08-03.10.23.02.mov