Cannot edit text in the middle of the Merchant field without cursor jumping to the end

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.53-8
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @heyjennahay
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

Precondition: New manual expense flow beta enabled

1. Click Global + > Create an expense.
2. Enter some text in the Merchant field, for example United Airlines.
3. Place the cursor somewhere in the middle of the existing text.
4. Attempt to type a new word or additional text.
5. Observe the cursor position after entering each character.

Expected Result:

The cursor should remain at the selected insertion point.
Users should be able to type an entire word or edit existing text in the middle of the Merchant field, just as they can in the Description field.

Actual Result:

After entering each character, the cursor jumps to the end of the Merchant field.
Users cannot type a complete word in the middle of the existing merchant text without repeatedly repositioning the cursor.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

2026-08-13_23-40-58.mp4

Recording.3369.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022088251485959027156
• Upwork Job ID: 2088251485959027156
• Last Price Increase: 2026-08-14

Issue Owner

Current Issue Owner: @thelullabyy

[MelvinBot]

Proposal

What is the root cause of that problem?

In the new manual expense flow, the Merchant field is a plain, fully-controlled TextInput whose value only updates through an asynchronous Onyx round-trip, and it passes no selection prop.

On each keystroke, handleMerchantInputChange calls setMoneyRequestMerchant → Onyx.merge(...) (async) and returns without any synchronous local state update. React re-renders with the stale value, so react-native-web re-asserts the DOM input's .value. Because no selection is supplied, RNW never restores the caret and it snaps to the end.

The Description field in the same flow is immune because it uses type="markdown" (react-native-live-markdown's MarkdownTextInput), which is not a React-DOM-controlled <input> and imperatively tracks/restores its own caret across value updates.

Evidence

• Merchant input (new-flow branch), controlled value + no selection: src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx:110-125
• value derived from async Onyx state via useTransactionSelector: MerchantField.tsx:59-62
• Change handler persists to Onyx and returns, no synchronous mirror: MerchantField.tsx:86-108
• Description uses type="markdown" (MarkdownTextInput), which preserves the caret: src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx:134
• RNW plain TextInput restores the caret only when a selection prop is passed (node_modules/react-native-web/.../TextInput/index.js useLayoutEffect guarded by selection != null).

Note: the standalone Merchant page (IOURequestStepMerchant.tsx:200-205) does not have this bug because it uses an uncontrolled defaultValue input and only persists on submit — corroborating that the per-keystroke controlled round-trip is the trigger.

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

In MerchantField.tsx, stop feeding the plain TextInput a value that lags behind the DOM. Pick one:

1. Local synchronous mirror (recommended, smallest, matches existing patterns): keep a useState mirror of the text, set it synchronously at the top of handleMerchantInputChange, use it as value, and re-sync from Onyx via an effect when displayMerchantValue changes while the input isn't focused. The controlled value then matches the DOM each keystroke, so the caret never resets.
2. Track selection: add onSelectionChange to store {start, end} and pass it back as the selection prop so RNW restores the caret after the value is re-asserted.
3. Make it uncontrolled like the standalone page (defaultValue + persist on blur/submit).

What alternative solutions did you explore? (Optional)

Switching the Merchant input to type="markdown" would sidestep the caret handling (as Description does), but that's a heavier change than needed for a plain single-line field.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/9c03810de4e9b67a581081cfeb56ef75ce414317/src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx#L110-L125) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[j3ffffff]

Proposal

What is the root cause of that problem?

The Merchant field in the new manual expense flow (src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx) renders a plain TextInput (no type prop, so it defaults to RNTextInput — a standard controlled <input> element on web). Its value prop is wired directly to Onyx via useTransactionSelector + merchantStateSelector:

1. User types a character mid-word → handleMerchantInputChange fires → setMoneyRequestMerchant calls Onyx.merge(...) (asynchronous).
2. Onyx notifies subscribers on the next tick → merchantState updates → displayMerchantValue recomputes → component re-renders with a new value prop.
3. Because this re-render happens outside the original keystroke event context, React has no cursor-preservation logic in play; it sets input.value = displayMerchantValue on the DOM element, which the browser responds to by moving the cursor to the end.

The Description field (DescriptionField.tsx) does not exhibit this bug because it passes type="markdown" to TextInput. That type resolves to RNMarkdownTextInput (from @expensify/react-native-live-markdown), which renders as a contenteditable div on web. contenteditable elements manage cursor/selection via the browser's native Selection API; updating the element's content programmatically does not move the cursor, so the cursor stays where the user placed it.

Key code locations:

• src/components/TextInput/BaseTextInput/implementations.ts (lines 9–13): InputComponentMap maps 'default' → RNTextInput, 'markdown' → RNMarkdownTextInput.
• src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx (lines 110–122): the new-flow TextInput has no type prop.
• src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx (lines 123–136): the new-flow TextInput has type="markdown".

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

The root fix is to decouple the displayed merchant value from the async Onyx round-trip. Add a local useState to MerchantField that holds the current input value and updates synchronously on every keystroke. Pass that local state as value to the TextInput (so the DOM value is always up-to-date from the user's perspective without an async gap). Continue writing to Onyx from handleMerchantInputChange as before — Onyx remains the source of truth for persistence, but the display value is no longer subject to an async re-render cycle that moves the cursor.

The local state should be initialized from displayMerchantValue (on mount / when the transactionID changes) so that pre-filled merchant values (e.g., from SmartScan or a draft) still appear correctly.

This is the same pattern that would be needed for any single-line controlled field that writes to Onyx on each keystroke; the Description field avoids the problem differently (via its custom renderer), but the merchant fix should be self-contained within MerchantField.tsx.

What alternative solutions did you explore? (Optional)

• Add type="markdown" to the Merchant TextInput: Would incidentally fix the cursor issue (because it switches to contenteditable), but is semantically wrong — merchant is a plain single-line string field, not a markdown document, and would introduce unintended markdown rendering.
• Save/restore selection with a ref: Manually save selectionStart/selectionEnd before onChangeText and restore them in a useEffect after displayMerchantValue changes. This would work but is more fragile and harder to maintain than the local-state approach.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022088251485959027156

[pvaghasiya087-has]

Proposal

What is the root cause of that problem?

I traced the new manual expense flow from MerchantField.tsx through useTransactionSelector().

MerchantField currently derives displayMerchantValue from the transaction selector and passes it directly to the default controlled TextInput:

<TextInput
    value={displayMerchantValue}
    readOnly={didConfirm}
    onChangeText={handleMerchantInputChange}
    ...
/>

useTransactionSelector() subscribes to the split draft when editing a split bill, otherwise the transaction draft with the existing transaction as fallback. Therefore, the value rendered by the input is tied directly to the Onyx-backed transaction state.

At the same time, handleMerchantInputChange() writes every keystroke back to that same state through setDraftSplitTransaction() or setMoneyRequestMerchant().

This creates a controlled-input feedback loop:

user types
   ↓
TextInput onChangeText
   ↓
setDraftSplitTransaction / setMoneyRequestMerchant
   ↓
Onyx transaction state changes
   ↓
useTransactionSelector re-renders
   ↓
displayMerchantValue changes
   ↓
TextInput receives the controlled value again
   ↓
caret is reset

When the user is editing at the end, this is not noticeable because the caret is already at the end. When editing in the middle, the controlled value update causes the caret to be lost, producing the reported behavior.

This is also why I would not change the Merchant field to type="markdown". Expensify intentionally maps the default input and Markdown input to different implementations; Description uses the Markdown implementation, while Merchant currently uses the normal RNTextInput.

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

I would separate the active UI editing value from the persisted transaction value.

The existing transaction actions should remain responsible for persistence, but the TextInput should immediately render the value supplied by the user instead of waiting for the Onyx round trip.

I would add a local merchantInput state and synchronize it from displayMerchantValue only when the field is not actively being edited:

const [merchantInput, setMerchantInput] = React.useState(displayMerchantValue);
const [isMerchantFocused, setIsMerchantFocused] = React.useState(false);

React.useEffect(() => {
    if (!isMerchantFocused) {
        setMerchantInput(displayMerchantValue);
    }
}, [displayMerchantValue, isMerchantFocused]);

The existing handler can then update the local value first and keep the current persistence branches unchanged:

const handleMerchantInputChange = (newMerchant: string) => {
    setMerchantInput(newMerchant);

    if (!transactionID) {
        return;
    }

    if (isEditingSplitBill) {
        if (newMerchant.trim() === '') {
            setDraftSplitTransaction(transactionID, splitDraftTransaction, {
                merchant: '',
                isMerchantSet: false,
            });
            return;
        }

        setDraftSplitTransaction(transactionID, splitDraftTransaction, {
            merchant: newMerchant,
        });
        return;
    }

    if (newMerchant.trim() === '') {
        clearMoneyRequestMerchant(transactionID);
        return;
    }

    setMoneyRequestMerchant(transactionID, newMerchant, true, transactionHasReceipt);
};

Then the new-flow input becomes:

<TextInput
    value={merchantInput}
    readOnly={didConfirm}
    onFocus={() => setIsMerchantFocused(true)}
    onBlur={() => setIsMerchantFocused(false)}
    onChangeText={handleMerchantInputChange}
    label={translate('common.merchant')}
    accessibilityLabel={translate('common.merchant')}
    errorText={merchantErrorText}
/>

The important detail is that the existing setDraftSplitTransaction(), clearMoneyRequestMerchant(), and setMoneyRequestMerchant() behavior is not replaced. They continue updating the correct transaction source. Only the value rendered during an active edit is decoupled from that asynchronous state update.

I would also reset the local value when transactionID changes so navigating between transactions cannot retain an old merchant value:

React.useEffect(() => {
    setMerchantInput(displayMerchantValue);
}, [transactionID]);

The synchronization should be implemented carefully so an external transaction update does not overwrite text that the user is currently entering.

What alternative solutions did you explore? (Optional)

I considered restoring the caret with onSelectionChange and the selection prop.

Although React Native supports selection control, that approach would require manually maintaining and restoring caret/selection state whenever the controlled value changes. It also adds platform-specific behavior to a field that can be fixed at its state boundary.

I also considered changing Merchant to the Markdown input used by Description, but Expensify's input mapping shows that these are deliberately different input implementations, and Merchant is a plain single-line value rather than Markdown.

The local editing-value approach keeps the fix isolated to MerchantField, preserves the existing transaction persistence architecture, and avoids modifying the shared TextInput component.

I would verify the change by testing:

• inserting characters at the beginning, middle, and end;
• typing a complete word without repositioning the cursor;
• replacing selected text;
• deleting characters from the middle;
• clearing the Merchant field;
• editing a pre-filled merchant;
• split-bill merchant editing;
• switching between transactions;
• external transaction value updates; and
• Android, iOS, and web, matching the platforms reported in the issue.

[trjExpensify]

Assigning the project team working on this (it's in beta).