[Due for payment 2026-08-10] [$250] [Sentry: APP-GVV] IndexSizeError restoring markdown cursor on IOU description step

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-GVV

Impact (snapshot at filing)

• Users (total since first seen): 1
• Events: 1
• Users (last 14d): 1
• First seen: 2026-07-02
• Last seen: 2026-07-02
• Platform: web
• App version(s): 9.4.25-2
• Affected route(s) (parameterized): /create/submit/description/:action/:iouType/:transactionID
• Mechanism: auto.browser.global_handlers.onerror

Stack trace (top frames, first-party only)

IOURequestStepDescription.tsx:172 (t16) → inputRef.current?.focus()
useDiscardChangesConfirmation/index.ts:80 → onCancel?.()
MarkdownTextInput.web.js:411 (handleFocus) → setCursorPosition
cursorUtils.js:27 (setCursorPosition) → range.setStart

Suspected cause

useDiscardChangesConfirmation onCancel calls inputRef.focus() which triggers live-markdown setCursorPosition with stale DOM offsets after the description field content changed.

Reproduction

1. Open expense description step in create/submit flow.
2. Edit description, then cancel/discard changes (triggering discard confirmation).
3. Observe IndexSizeError on Range.setStart in console.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077755966792443403
• Upwork Job ID: 2077755966792443403
• Last Price Increase: 2026-07-16

Issue Owner

Current Issue Owner: @suneox

[melvin-bot]

Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @suneox (External)

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 14:11:56 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On web, an uncaught IndexSizeError is thrown from Range.setStart while restoring the markdown cursor on the IOU description step. It is reproduced by opening the expense description step, editing the description, then triggering the discard-changes confirmation and cancelling it. The error is captured by Sentry (APP-GVV) via the global onerror handler.

What is the root cause of that problem?

When the discard-changes confirmation is cancelled, the description step re-focuses the input:

App/src/pages/iou/request/step/IOURequestStepDescription.tsx

Lines 179 to 184 in 21dd5a0

	useDiscardChangesConfirmation({
	onCancel: () => {
	inputRef.current?.focus();
	},
	getHasUnsavedChanges: () => {
	if (isSaved) {

Focusing the markdown input runs handleFocus in @expensify/react-native-live-markdown, which restores the previous caret by calling setCursorPosition with the last remembered selection. setCursorPosition computes the DOM offset from the markdown tree metadata and passes it straight into Range.setStart/Range.setEnd:

range.setStart((startElement.childNodes[0] || startElement), start - startTreeNode.start) (node_modules/@expensify/react-native-live-markdown/src/web/utils/cursorUtils.ts, the setStart/setEnd lines inside setCursorPosition).

The starting index is clamped to target.tree.length, but the resulting offset is only validated against the tree node's length, not against the actual length of the resolved DOM node (startElement.childNodes[0]). When the tree metadata is momentarily out of sync with the rendered DOM text node — which happens here because the input is blurred while the discard modal is open and then programmatically re-focused — the computed offset can exceed the real text node length. Range.setStart/Range.setEnd throw IndexSizeError whenever the offset is greater than the node length, and nothing catches it, so it surfaces as the crash.

What changes do you think we should make in order to solve the problem?

Make the caret restoration in setCursorPosition (in @expensify/react-native-live-markdown, src/web/utils/cursorUtils.ts) resilient to a transient tree/DOM desync by clamping each offset to the bounds of the DOM node it is applied to, before calling Range.setStart/Range.setEnd:

• Resolve the container node first (startElement.childNodes[0] || startElement for the start, and the equivalent for the end).
• Compute the offset as today (start - startTreeNode.start), then clamp it to that node's maximum valid offset: for a text node that is its .length, and for an element node that is its childNodes.length.
• Pass the clamped offset into Range.setStart/Range.setEnd.

With the offset clamped to the node's real bounds, the range API can no longer receive an out-of-range offset, so the IndexSizeError cannot be thrown. In the rare desync case the caret lands at the end of the node instead of crashing, and the next parse pass re-syncs it to the correct position — a graceful degradation instead of an app-level error.

Because this fix lives in the bundled @expensify/react-native-live-markdown library, it should be applied to App as a patch-package patch against version 0.1.329 (and upstreamed to the library repo), matching how other library-level fixes ship in App. The patch needs to cover the library's compiled lib/module and lib/commonjs builds in addition to src, because the web bundle resolves the package's module entry point rather than its source — patching src alone would have no effect on web, which is where this error occurs.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/95347-clamp-markdown-cursor-offset?expand=1

What alternative solutions did you explore? (Optional)

Wrapping the range.setStart/range.setEnd calls in setCursorPosition in a try/catch that swallows the IndexSizeError and returns early. This also stops the crash, but it silently abandons cursor restoration on any failure rather than placing the caret at the nearest valid position, so clamping the offset is preferred as it keeps the caret behaviour correct while still being crash-safe.