[$250] Travel - Cursor position is in the end for Monthly spend limit per member field

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.74-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177079/test-cases/103853318
Email or phone of affected tester (no customers): expensifail account
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Ventura / Chrome
App Component: Other

Action Performed:

Precondition: workspace with enabled Travel feature. Central invoicing feature is ON.

1. Go to Worksapce > Travel tab
2. Scroll down the page
3. Click on Monthly spend limit per member row

Expected Result:

Amount field is focused.
Cursor is in the beginning.
User can input new amount.

Actual Result:

Amount field is focused.
Cursor is in the end.
User can't input new amount. Need to move cursor to the beginning.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022055298234964395594
• Upwork Job ID: 2055298234964395594
• Last Price Increase: 2026-05-22

[MelvinBot]

Proposal

What is the root cause of that problem?

In NumberWithSymbolForm.tsx, when displayAsTextInput is true (which is how the Monthly Limit page renders its amount field), the rendered <TextInput> does not receive the selection prop. Without an explicit selection, the native input defaults to placing the cursor at the end of the pre-populated text.

The component does maintain a selection state, and passes it correctly in the non-displayAsTextInput path (BigNumberPad mode), but it is simply omitted in the displayAsTextInput branch.

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

1. Initialize the selection state to {start: 0, end: 0} instead of {start: currentNumber.length, end: currentNumber.length} so the cursor starts at the beginning when the field is pre-populated.
2. Pass selection={selection} and an onSelectionChange handler to the <TextInput> in the displayAsTextInput branch of NumberWithSymbolForm.tsx, mirroring how it's already done in the non-displayAsTextInput path.

What alternative solutions did you explore? (Optional)

• Handling this per-page (e.g. in WorkspaceTravelInvoicingMonthlyLimitPage) via an onFocus callback that sets selection to {start: 0, end: 0}. This would work but is fragile — every page using displayAsTextInput with a default value would need the same fix. Fixing it in NumberWithSymbolForm addresses all affected pages at once.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-15 14:52:42 UTC.

Proposal

What is the root cause of that problem?

NumberWithSymbolForm.tsx's displayAsTextInput branch (L488-L522) hands the underlying <TextInput> no cursor/selection control — neither selection, nor selectTextOnFocus, nor a focus-time selection handler. The non-keypad mode is the only path that omits this; the BigNumberPad branch at L543 does pass selection={selection} and works correctly.

Combined with WorkspaceTravelInvoicingMonthlyLimitPage.tsx#L38-L39, which always seeds the field with a 2-decimal string (convertToFrontendAmountAsString(currentLimit, CONST.DEFAULT_CURRENCY_DECIMALS) → "0.00" when no limit is set), this lands a Chrome/Safari user on a focused input with the caret browser-defaulted to the end of "0.00". The very next condition in setFormattedNumber — validateAmount(withLeadingZero, decimals=2, ...) — then rejects every keystroke because appending a digit at the end ("0.005", "0.001", …) exceeds decimals=2. The field looks frozen until the user manually moves the caret.

The page itself was introduced by PR #86398 (merged 2026-04-15, file added by commit ff28e2a180d), which is why this surfaces now as a regression. The same latent defect lives on the two other displayAsTextInput + 2-decimal-default consumers — RulesMaxExpenseAmountPage.tsx#L74-L82 and RulesAutoApproveReportsUnderPage.tsx#L72-L80 — which is why the fix belongs in the shared component, not the page.

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

Add selectTextOnFocus to the <TextInput> in the displayAsTextInput branch of NumberWithSymbolForm.tsx. This is the Expensify-standard pattern for "auto-focus a pre-populated input and let the first keystroke replace it" and is already used at SearchBar.tsx#L45, AddressSearch/index.tsx#L488, and SelectionList/components/TextInput.tsx#L162.

                 keyboardType={props.keyboardType ?? CONST.KEYBOARD_TYPE.DECIMAL_PAD}
+                selectTextOnFocus
                 // On android autoCapitalize="words" is necessary when keyboardType="decimal-pad" or inputMode="decimal" to prevent input lag.
                 // See https://github.com/Expensify/App/issues/51868 for more information
                 autoCapitalize="words"

On focus (programmatic from useAutoFocusInput.focus() at useAutoFocusInput.ts#L87 or user-initiated), the existing "0.00" (or a prior limit such as "100.00") is selected, the first keystroke replaces the selection, and validateAmount accepts the result because the typed digit reduces total length below the decimal boundary instead of pushing past it.

This is materially stronger than cursor-at-start: with caret at position 0 on a pre-existing "100.00", typing 5 yields "5100.00" — not the user's intent of "5". Select-all-on-focus matches the MoneyRequestAmountInput convention used everywhere else amounts are edited in NewDot, so the Travel limit field behaves like every other amount field in the app.

Because the fix sits in the shared component's displayAsTextInput branch, the two latent siblings (RulesMaxExpenseAmountPage, RulesAutoApproveReportsUnderPage) are repaired in the same change with zero additional diff.

What alternative solutions did you explore?

• Init the controlled selection state to {start: 0, end: 0} and thread selection={selection} + onSelectionChange into the displayAsTextInput TextInput (cursor-at-start). Fixes the literal QA wording but still produces wrong amounts in the edit case ("5100.00" instead of "5"); requires ~4 lines of state plumbing where selectTextOnFocus is one line and zero state. Worth using only as a fallback if selectTextOnFocus is ever found to no-op on programmatic focus in some web build — the in-repo precedent (SearchBar, AddressSearch, SelectionList) contradicts that.
• Conditional empty defaultValue on the Travel page (currentLimit ? convertToFrontendAmountAsString(...) : ''). Fixes only the no-prior-limit case; if a workspace already has a limit, the field still opens at "100.00" with the caret at the end and the same validateAmount rejection blocks typing. Also doesn't reach the two Rules-page siblings that share the bug shape.
• Page-level onFocus handler calling input.setSelectionRange(0, 0) on the underlying DOM node. Web-only DOM escape hatch; bypasses the RN abstraction; cursor-at-start has the same edit-case weakness as above; needs to be duplicated across all three affected pages instead of fixed once in the shared component.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-15 15:07:37 UTC.

Proposal

What is the root cause of that problem?

There are actually two cooperating bugs that together produce the end-of-field cursor:

1. The page seeds the input with "0.00" even when no limit has been set.

travelSettings?.monthlySpendLimitPerUser is number | undefined, but the page coerces it to 0 and formats it unconditionally:

https://github.com/Expensify/App/blob/main/src/pages/workspace/travel/WorkspaceTravelInvoicingMonthlyLimitPage.tsx#L38-L40

So when the workspace has no monthly limit configured yet, the AmountForm opens pre-populated with "0.00" instead of an empty input. Every other limit page (RulesMaxExpenseAmountPage, RulesMaxExpenseAgePage, CategorySettingsPage …) follows the opposite convention and falls back to '' when the limit is unset.

2. NumberWithSymbolForm never wires selection through in displayAsTextInput mode.

The component maintains a controlled selection state initialized at the end of the value:

https://github.com/Expensify/App/blob/main/src/components/NumberWithSymbolForm.tsx#L205-L208

…but the displayAsTextInput branch renders the inner TextInput without passing selection or onSelectionChange, so the controlled selection is computed and then ignored:

https://github.com/Expensify/App/blob/main/src/components/NumberWithSymbolForm.tsx#L476-L509

Compare with the BigNumberPad branch a few lines below, which does pass them through:

https://github.com/Expensify/App/blob/main/src/components/NumberWithSymbolForm.tsx#L530-L546

The combined effect: with displayAsTextInput + autoFocus + a non-empty initial value ("0.00"), the platform TextInput falls back to its default focus behavior, which on iOS/Android/web is "caret at end of value." That is exactly what QA flagged.

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

I'd fix both the symptom on this page and the underlying component gap.

Fix 1 — Page: don't render "0.00" for an unset limit (mirrors RulesMaxExpenseAmountPage here):

- const currentLimit = travelSettings?.monthlySpendLimitPerUser ?? 0;
- const defaultValue = convertToFrontendAmountAsString(currentLimit, CONST.DEFAULT_CURRENCY_DECIMALS);
+ const currentLimit = travelSettings?.monthlySpendLimitPerUser ?? 0;
+ const defaultValue = currentLimit ? convertToFrontendAmountAsString(currentLimit, CONST.DEFAULT_CURRENCY_DECIMALS) : '';

currentLimit stays a number because handleSubmit / submitLimit use it to detect "is the user reducing the limit". On first entry the input is now empty, so the auto-focus places the caret at position 0 — matching the expected behavior.

Fix 2 — Component: honor selection in displayAsTextInput mode. When a limit is already configured (e.g. $500.00) the same screen would still drop the caret at the end, because selection isn't plumbed through that branch. The minimal change is to pass it through and initialize the controlled selection at the start when the form mounts with a non-empty value:

  return (
      <TextInput
          label={label}
          accessibilityLabel={label}
          value={formattedNumber}
          onChangeText={setFormattedNumber}
          ...
          autoFocus={props.autoFocus}
+         selection={selection}
+         onSelectionChange={(e) => {
+             const {start, end} = e.nativeEvent.selection;
+             setSelection({start, end});
+         }}
          ...
      />
  );

…together with initializing selection at {start: 0, end: 0} when displayAsTextInput is true and there is an existing value, so the caret lands before the first digit instead of after the last one. After that, the existing setNewNumber machinery already keeps the selection in sync as the user types.

This makes the controlled-selection contract consistent between the BigNumberPad and TextInput branches and prevents the same regression from reappearing on every other page that uses <AmountForm displayAsTextInput /> with a pre-filled value (PolicyDistanceRateEditPage, WorkspaceEditCardLimitPage, etc.).

What alternative solutions did you explore? (Optional)

• Select-all on focus. I considered adding a selectTextOnFocus-style prop so the existing value is fully selected when the field gains focus, letting the user type to replace. It's a nicer UX, but it changes the expected behavior described in the issue (caret at beginning, not selection) and would require careful handling of the prefix character and decimal point on Android.
• Page-only fix without touching the component. Cheaper, but it only papers over the unset-limit case; once a user has configured $500.00, returning to the page reproduces the same caret-at-end behavior. The component-level fix is what stops the bug from recurring.
• Introduce a sentinel like DISABLED_MAX_EXPENSE_VALUE for travel. Rejected — the travel-invoicing backend stores null / undefined, not a magic value, so this would only add client-side complexity.

[melvin-bot]

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

[melvin-bot]

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

[aswin-s]

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

When a user opens the Monthly spend limit per member field in the Workspace Travel tab (with Central invoicing enabled), the amount input auto-focuses with the previous amount prefilled, but the cursor is positioned at the end of the text instead of the beginning. This forces users to manually move the cursor to the start before they can input a new amount, creating unnecessary friction in the form.

What is the root cause of that problem?

The root cause is in src/pages/workspace/travel/WorkspaceTravelInvoicingMonthlyLimitPage.tsx lines 40–50. The page renders an InputWrapper with AmountForm (using displayAsTextInput) and passes ref={inputCallbackRef} to enable useAutoFocusInput. When the input auto-focuses with a prefilled defaultValue, the browser's default behavior places the cursor at the end of the text. The displayAsTextInput branch of NumberWithSymbolForm does not forward a selection prop to position the caret, and the page provides no onFocus handler to correct the cursor position.

App/src/pages/workspace/travel/WorkspaceTravelInvoicingMonthlyLimitPage.tsx

Lines 40 to 50 in b1e71d7

	const {inputCallbackRef} = useAutoFocusInput();
	const {showConfirmModal} = useConfirmModal();
	const submitLimit = (newLimitInCents: number) => {
	updateTravelInvoicingMonthlyLimit(workspaceAccountID, newLimitInCents, currentLimit);
	Navigation.setNavigationActionToMicrotaskQueue(Navigation.goBack);
	};
	const validate = ({
	limit,
	}: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_TRAVEL_INVOICING_MONTHLY_LIMIT_FORM>): FormInputErrors<typeof ONYXKEYS.FORMS.EDIT_TRAVEL_INVOICING_MONTHLY_LIMIT_FORM> => {

For comparison, NumberWithSymbolForm (the working analog) manages cursor position through a selection state that can be set to control where the caret appears:

App/src/components/NumberWithSymbolForm.tsx

Lines 1 to 50 in b1e71d7

	import {useIsFocused} from '@react-navigation/native';
	import type {ForwardedRef} from 'react';
	import React, {useCallback, useEffect, useImperativeHandle, useMemo, useRef, useState} from 'react';
	import type {KeyboardTypeOptions, NativeSyntheticEvent, StyleProp, TextStyle, ViewStyle} from 'react-native';
	import {View} from 'react-native';
	import useIsInLandscapeMode from '@hooks/useIsInLandscapeMode';
	import {useMemoizedLazyExpensifyIcons} from '@hooks/useLazyAsset';
	import useLocalize from '@hooks/useLocalize';
	import {useMouseActions} from '@hooks/useMouseContext';
	import usePrevious from '@hooks/usePrevious';
	import useStyleUtils from '@hooks/useStyleUtils';
	import useThemeStyles from '@hooks/useThemeStyles';
	import {isMobileSafari} from '@libs/Browser';
	import {canUseTouchScreen as canUseTouchScreenUtil} from '@libs/DeviceCapabilities';
	import getOperatingSystem from '@libs/getOperatingSystem';
	import {
	addLeadingZero,
	handleNegativeAmountFlipping,
	replaceAllDigits,
	replaceCommasWithPeriod,
	stripCommaFromAmount,
	stripDecimalsFromAmount,
	stripSpacesFromAmount,
	validateAmount,
	} from '@libs/MoneyRequestUtils';
	import shouldIgnoreSelectionWhenUpdatedManually from '@libs/shouldIgnoreSelectionWhenUpdatedManually';
	import CONST from '@src/CONST';
	import BigNumberPad from './BigNumberPad';
	import Button from './Button';
	import FormHelpMessage from './FormHelpMessage';
	import ScrollView from './ScrollView';
	import TextInput from './TextInput';
	import isTextInputFocused from './TextInput/BaseTextInput/isTextInputFocused';
	import type {BaseTextInputRef} from './TextInput/BaseTextInput/types';
	import TextInputWithCurrencySymbol from './TextInputWithSymbol';
	import type {TextInputWithSymbolProps} from './TextInputWithSymbol/types';
	type NumberWithSymbolFormProps = {
	/** Value to display, should already be formatted */
	value?: string;
	/** Callback to update the value in the FormProvider */
	onInputChange?: (number: string) => void;
	/** Number of decimals to display in the number */
	decimals?: number;
	/** Currency of the input */
	currency?: string;

This bug is web-only (Chrome/Safari on macOS and Windows), consistent with the checked platforms in the issue. On native iOS and Android, React Native's TextInput uses the selection prop for caret placement rather than the DOM's setSelectionRange, so no cursor mis-positioning occurs on those platforms.

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

1. File: src/pages/workspace/travel/WorkspaceTravelInvoicingMonthlyLimitPage.tsx
   Function: WorkspaceTravelInvoicingMonthlyLimitPage
   Edit: Add an onFocus handler to the InputWrapper that resets the selection range to the beginning (position 0) immediately after the input receives focus. The handler receives the native focus event, reads event.target (which is always a populated HTMLInputElement at the time onFocus fires — no async race is possible because React's synthetic onFocus is dispatched synchronously after the element gains focus and the DOM value is already set by the controlled/uncontrolled value at mount), and only calls setSelectionRange when the element supports it and the current value is non-empty, avoiding no-op calls on empty inputs.

const handleFocus = (event: React.FocusEvent<HTMLInputElement>) => {
    const input = event.target;
    if (input && typeof input.setSelectionRange === 'function' && input.value.length > 0) {
        input.setSelectionRange(0, 0);
    }
};

Pass this handler to InputWrapper as onFocus={handleFocus}. This is a web-only DOM API (setSelectionRange) and is not called on native platforms, so no platform guard is needed — React Native will never reach this code path.

What alternative solutions did you explore? (Optional)

N/A

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[github-actions]

⚠️ @dilshodmackbook-sketch Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.