Fatal Exception: java.lang.StringIndexOutOfBoundsException: begin 2, end 52, length 50

[mianaliasjad]

I have been using this awesome library in my app for one year. This exception was occurring in the version v1.0.0-rc13 but then I saw the change log of version v1.0.0-rc14 and it specified the fix of StringIndexOutOfBoundsException. But it is still showing up in the version v1.0.0-rc14, maybe it's another variant of the same exception.

Fatal Exception: java.lang.StringIndexOutOfBoundsException: begin 2, end 52, length 50 at java.lang.String.checkBoundsBeginEnd(String.java:4930) at java.lang.String.substring(String.java:2948) at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.append-UJKp_GQ(AnnotatedStringExt.kt:142) at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.appendRichSpan-XtCa3Zc(AnnotatedStringExt.kt:56) at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.appendRichSpan-XtCa3Zc$default(AnnotatedStringExt.kt:42) at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.append-UJKp_GQ(AnnotatedStringExt.kt:28) at com.mohamedrejeb.richeditor.model.RichTextState.updateAnnotatedString$richeditor_compose_release(RichTextState.kt:2324) at com.mohamedrejeb.richeditor.model.RichTextState.updateTextFieldValue(RichTextState.kt:2113) at com.mohamedrejeb.richeditor.model.RichTextState.updateTextFieldValue$default(RichTextState.kt:2080) at com.mohamedrejeb.richeditor.model.RichTextState.onTextFieldValueChangeInner(RichTextState.kt:2072) at com.mohamedrejeb.richeditor.model.RichTextState.onTextFieldValueChange$richeditor_compose_release(RichTextState.kt:1974) at com.mohamedrejeb.richeditor.ui.BasicRichTextEditorKt.BasicRichTextEditor$lambda$9$1$0(BasicRichTextEditor.kt:276) at androidx.compose.foundation.text.BasicTextFieldKt.BasicTextField$lambda$27$0(BasicTextField.kt:912) at androidx.compose.foundation.text.LegacyTextFieldState.onValueChange$lambda$0(LegacyTextFieldState.java:909) at androidx.compose.foundation.text.TextFieldDelegate$Companion.onEditCommand$foundation(TextFieldDelegate.java:293) at androidx.compose.foundation.text.TextFieldDelegate$Companion.restartInput$lambda$0(TextFieldDelegate.java:342) at androidx.compose.foundation.text.input.internal.LegacyTextInputMethodRequest$createInputConnection$1.onEditCommands(LegacyTextInputMethodRequest.java:274) at androidx.compose.foundation.text.input.internal.RecordingInputConnection.endBatchEditInternal(RecordingInputConnection.android.kt:191) at androidx.compose.foundation.text.input.internal.RecordingInputConnection.endBatchEdit(RecordingInputConnection.java:185) at androidx.compose.ui.text.input.NullableInputConnectionWrapperApi21.endBatchEdit(NullableInputConnectionWrapperApi21.java:150) at android.view.inputmethod.RemoteInputConnectionImpl.lambda$endBatchEdit$35(RemoteInputConnectionImpl.java:1002) at android.view.inputmethod.RemoteInputConnectionImpl.$r8$lambda$dyvX76mWLIMlRRSgQ0CT-rRsrEE() at android.view.inputmethod.RemoteInputConnectionImpl$$ExternalSyntheticLambda13.run(D8$$SyntheticClass) at android.os.Handler.handleCallback(Handler.java:1037) at android.os.Handler.dispatchMessage(Handler.java:108) at android.os.Looper.loopOnce(Looper.java:304) at android.os.Looper.loop(Looper.java:430) at android.app.ActivityThread.main(ActivityThread.java:9345) at java.lang.reflect.Method.invoke(Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:593) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:953)

[MohamedRejeb]

Hello
Thanks for reporting this, can you send steps to reproduce this, what html caused this crash that would help fixing it.

[mianaliasjad]

@MohamedRejeb unofrtunatly i saw this crash on Google Crashlytics happening on real user devices, so i don't know the exact text state which caused it.

[MohamedRejeb]

I see, ok I will try to provide more informations in the crash so we can fix this.

[mikelburkhart]

We are seeing this in our production deployment as well. I've burned some genAI tokens (opus 4.6) on the issue and wanted to provide the recommended fix:

Bug Report: StringIndexOutOfBoundsException in AnnotatedStringExt.kt:142 — Span Tree / Text Desync During IME Batch Edits

Summary

updateAnnotatedString() crashes with StringIndexOutOfBoundsException when the internal richParagraphList span tree and the
TextFieldValue.text string become length-mismatched. This happens when the Compose TextField delivers a stale text value (from a pending
IME endBatchEdit) after the span tree has been rebuilt by a programmatic setHtml() call.

Crash Location

AnnotatedStringExt.kt:142 in the append() overload that maps span text from the raw string:

val newText = text.substring(index, index + richSpan.text.length)

When the sum of richSpan.text.length values across the span tree exceeds text.length, this substring() call throws
StringIndexOutOfBoundsException.

Root Cause

The crash is a race condition between programmatic state mutations and the Android IME pipeline:

1. The app calls state.setHtml(newHtml) in a snapshotFlow collector (responding to text changes near hyperlink spans).
2. setHtml() rebuilds richParagraphList from the new HTML — the span tree now reflects the new content.
3. Compose's TextField sees the value change and calls restartInput() to reset the IME connection.
4. During restartInput(), the old IME connection's pending endBatchEdit fires (this is a documented race in RecordingInputConnection).
5. The old batch delivers a TextFieldValue whose .text is based on the previous content (before setHtml).
6. onTextFieldValueChange → updateTextFieldValue → updateAnnotatedString(staleTextFieldValue) is called.
7. The span tree (rebuilt from new HTML) expects text.length >= totalSpanTextLength, but the stale text is shorter → crash.

Stack Trace (from production)

java.lang.StringIndexOutOfBoundsException
at java.lang.String.substring (String.java:2537)
at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.append-UJKp_GQ (AnnotatedStringExt.kt:142)
at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.appendRichSpan-XtCa3Zc (AnnotatedStringExt.kt:56)
at com.mohamedrejeb.richeditor.utils.AnnotatedStringExtKt.append-UJKp_GQ (AnnotatedStringExt.kt:28)
at com.mohamedrejeb.richeditor.model.RichTextState.updateAnnotatedString (RichTextState.kt:2324)
at com.mohamedrejeb.richeditor.model.RichTextState.updateTextFieldValue (RichTextState.kt:2113)
...
at RecordingInputConnection.endBatchEditInternal (RecordingInputConnection.android.kt:191)
at RemoteInputConnectionImpl.lambda$endBatchEdit$35 (RemoteInputConnectionImpl.java:1009)

Conditions That Trigger It

• Required: A hyperlink (or any styled span with custom RichSpanStyle) exists in the editor content.
• Trigger: User types adjacent to the styled span using a predictive/swipe keyboard (Gboard, Samsung Keyboard). The IME delivers
  multi-character suggestions or autocorrections as batch edits that widen the timing window.
• Critical path: Any consumer code that calls setHtml(), setMarkdown(), or setText() programmatically from within a
  snapshotFlow/LaunchedEffect that observes state.annotatedString changes. The IME has no mechanism to know the span tree was rebuilt
  mid-flight.

Proposed Fix (In-Library)

Option A: Bounds-check in AnnotatedStringExt.kt (Defensive — prevents crash)

In the append() function at line ~142, clamp/validate the substring bounds:

// Before (crashes):
val newText = text.substring(index, index + richSpan.text.length)

// After (defensive):
val endIndex = index + richSpan.text.length
if (endIndex > text.length) {
// Span tree is out of sync with text — truncate or bail out safely.
// Option 1: Truncate span text to available length
val available = (text.length - index).coerceAtLeast(0)
richSpan.text = if (available > 0) text.substring(index, index + available) else ""
richSpan.textRange = TextRange(index, index + richSpan.text.length)
append(richSpan.text)
index += richSpan.text.length
// Skip children since we're in a desynced state
return@withStyle
}
val newText = text.substring(index, endIndex)

This prevents the crash but doesn't fix the underlying desync. A full re-sync should follow on the next frame.

Option B: Validate text length in updateAnnotatedString() (Root-cause guard)

At the top of updateAnnotatedString(), add a length consistency check:

internal fun updateAnnotatedString(newTextFieldValue: TextFieldValue = textFieldValue) {
val newText = if (singleParagraphMode)
newTextFieldValue.text
else
newTextFieldValue.text.replace('\n', ' ')

 // Guard: if span tree total text length doesn't match the incoming text,
 // the state is desynchronized (e.g., stale IME delivery after setHtml).
 // Skip this update — the next valid text change will re-sync.
 val expectedLength = richParagraphList.sumOf { it.totalTextLength() }
 if (expectedLength > newText.length) {
     // State is desynced — ignore this stale update.
     // Optionally log a warning for diagnostics.
     return
 }
 // ... rest of method

}

Where totalTextLength() recursively sums type.startText.length + children's text + separators.

Option C: Reject stale IME input in onTextFieldValueChange (Ideal fix)

Track a monotonically-increasing generation counter that increments on every programmatic mutation (setHtml, setMarkdown, setText, etc.).
In onTextFieldValueChange, compare the incoming text against the expected text derived from the current span tree. If they don't match
the expected state, discard the event:

internal fun onTextFieldValueChange(newTextFieldValue: TextFieldValue) {
// If a programmatic rebuild happened since the last accepted input,
// verify the incoming text matches expectations.
if (newTextFieldValue.text != textFieldValue.text &&
newTextFieldValue.text.length != computeExpectedTextLength()) {
// Stale IME delivery — discard.
return
}
// ... existing logic
}

Recommendation

Combine Options A + C for defense-in-depth:

• Option C prevents the desync from propagating into the state machine at all.
• Option A ensures that even if an unforeseen path delivers mismatched state, the library degrades gracefully instead of crashing.

Option B is simpler but has the drawback of silently dropping valid edits in edge cases where paragraph counts change during the same
frame.

Reproduction Hint

1. Create a RichTextState with HTML containing link text.
2. Observe state.annotatedString in a snapshotFlow.
3. When a change is detected adjacent to the link, call state.setHtml(modifiedHtml).
4. Use a predictive keyboard (Gboard with autocorrect) and type rapidly adjacent to the link.
5. The autocorrect replacement batch edit races with the setHtml rebuild → crash.

Environment Details

• Devices observed: Samsung Galaxy (Android 13+), various Pixel devices
• Keyboard: Samsung Keyboard (HoneyBoard), Gboard with predictive text
• Library version:
  1.0.0-rc14
• Compose Foundation: Uses LegacyTextFieldState / RecordingInputConnection path