[$250] Expense-After discarding changes and tapping Description composer jumps up, field not opened

[applause-bot]

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.44-0
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/13177075/test-cases/41237833
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iPhone 15 iOS 26.5.2
App Component: Money Requests

Action Performed:

1. Navigate to a 1:1 conversation and create an expense with a merchant and a description
2. Open the expense
3. Tap on the description
4. Change the description, then tap Back button
5. Tap "Discard changes" button
6. Tap the description again

Expected Result:

Description page is opened

Actual Result:

After discarding changes and tapping Description field again the composer jumps up, users stays in expense details, edit description screen is not opened

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7216050_1784863013808.Description.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7216050

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081799112529623213
• Upwork Job ID: 2081799112529623213
• Last Price Increase: 2026-07-29

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/61c9a037020fa9aabd919ca6b608b5a07219260099e2f6fe1f5001aa12c1a9b0

[MelvinBot]

Proposal

What is the root cause of that problem?

When you tap Discard changes, the Description edit route (STEP_DESCRIPTION) isn't cleanly removed from the navigation state, so it stays as (or matches) the "focused" route. The next tap on the Description field then calls Navigation.navigate(...STEP_DESCRIPTION...), but linkTo has a dedup guard that silently returns without pushing when the target already matches the focused route:

Evidence & data flow

• The Description row navigates with a plain Navigation.navigate(...) — same as Merchant/Date, which work fine, so the row itself isn't the bug: MoneyRequestView.tsx:1244
• The tap dies here — the guard bails when areNamesAndParamsEqual or arePathAndBackToEqual is true: linkTo/index.ts:172-175
• The stale route is left behind by the native discard interceptor, which replays the blocked goBack and resets its isReplayingBlockedNavigation flag synchronously: useDiscardChangesConfirmation/index.native.ts:57-66. This file was rewritten around the 9.4.44 window (commits eedf3c4ee, ff72f4599, 63890c9cc), which fits the regression timing and explains why it's iOS/native-only (the .ts web variant handles the replay differently).

Flow: tap Description → RHP opens → edit text → Back → discard interceptor shows modal → Discard replays the blocked goBack, RHP closes visually but STEP_DESCRIPTION survives/mis-resolves in nav state → tap Description again → linkTo sees it as already-focused → return (no push) → the tap falls through to the report composer, which is why the keyboard "jumps up".

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

Ensure the STEP_DESCRIPTION route is fully torn down when Discard is confirmed, so the next navigate isn't swallowed. The fix belongs in useDiscardChangesConfirmation/index.native.ts — the synchronous reset of isReplayingBlockedNavigation should be deferred until after the blocked navigation action has actually been applied to the nav state (e.g. reset it in a requestAnimationFrame/microtask after the dispatch, or gate it on the route removal completing), rather than in the same synchronous block as the dispatch.

⚠️ This is medium confidence. The manifestation point (the linkTo dedup guard swallowing the second navigate) is well-supported, but the exact reason the route survives discard should be confirmed on a device by logging navigationRef.getRootState() right before the second navigate and checking which branch of the linkTo guard fires. Recommend that check before committing to the fix location.

What alternative solutions did you explore? (Optional)

• Reset the description edit component's "unsaved changes" gate on discard so getHasUnsavedChanges returns false after discarding (IOURequestStepDescription.tsx:176-187).
• Making the guard in linkTo not silently drop a navigate to a route that is closing — riskier, as it's shared navigation infrastructure.

Possibly related (not duplicates): #95347 (IndexSizeError on the same description step) and #84246 (discard modal not showing on browser Back).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97127) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[linhvovan29546]

🆘 C+ Help Wanted

[aswin-s]

Proposal

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

On iOS, when a user edits an expense description, taps Back, and confirms "Discard changes", then taps the Description field again, the edit-description screen does not open — the composer briefly jumps up and the user stays on the expense details page. Expected: the Description edit page opens normally on the second tap.

What is the root cause of that problem?

In src/hooks/useDiscardChangesConfirmation/index.native.ts, confirmNavigation (lines 57-66) guards the replayed navigation with a ref: it sets isReplayingBlockedNavigation.current = true, dispatches the blocked action, then sets it back to false — all synchronously (lines 58-65). But react-navigation dispatches/re-invokes the usePreventRemove callback (lines 73-83) asynchronously, after confirmNavigation has already reset the flag to false. So when the deferred removal fires, isReplayingBlockedNavigation.current is already false and hasUnsavedChanges() may still be truthy, so the guard at line 75 fails and the discard replay is re-intercepted instead of completing cleanly. The screen is left in an inconsistent navigation state, so the next tap on Description fails to push the edit page. The producer of the wrong flag value is the synchronous reset at line 65; the consumer that misbehaves is the usePreventRemove guard at line 75.

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

1. In src/hooks/useDiscardChangesConfirmation/index.native.ts, keep isReplayingBlockedNavigation.current set to true across the async navigation boundary instead of resetting it synchronously in the same tick. Reset it after the dispatch has been processed (next tick), so the deferred usePreventRemove invocation for the replayed action still sees the flag as true and passes it straight through at line 75:

const confirmNavigation = () => {
    isReplayingBlockedNavigation.current = true;
    if (blockedNavigationAction.current) {
        navigationRef.current?.dispatch(blockedNavigationAction.current);
        blockedNavigationAction.current = undefined;
    } else {
        navigationRef.current?.goBack();
    }
    // Reset after react-navigation has processed the (async) removal, so the deferred
    // usePreventRemove re-invocation for this replay still sees the guard as active.
    requestAnimationFrame(() => {
        isReplayingBlockedNavigation.current = false;
    });
};

Behavior matrix:

Scenario	Before	After
Discard confirmed, replayed back nav	Flag already false when deferred guard fires → replay re-intercepted, screen left inconsistent; next Description tap fails	Flag still true when deferred guard fires → removal passes through; screen unmounts cleanly; next tap opens page
Cancel discard	modal dismissed, stays on screen (unchanged)	unchanged
Back with no unsaved changes	hasUnsavedChanges() false → passes through (unchanged)	unchanged

What alternative solutions did you explore? (Optional)

Resetting the flag inside the usePreventRemove callback itself (after the pass-through dispatch at line 76) was considered, but that couples the reset to a callback that may not fire on every navigation type (e.g. goBack with no blocked action), risking a permanently-stuck true flag; deferring the reset one tick in confirmNavigation is the minimal, path-independent fix.

[mukhrr]

Proposal

What is the root cause of that problem?

MenuItemWithTopDescription's onPress never fires. I instrumented that pressable's three handlers on device to find out why, and the press does start — it gets cancelled before it completes.

Tap	Handler sequence	Time to cancel
Normal tap (opens)	onPressIn → onPress → onPressOut	—
Tap right after Discard	onPressIn → onPressOut, no onPress	~118ms, both runs

Two conclusions:

1. The touch does reach the row. onPressIn fires every time. So this is not a blocked hit-test, a dead touch or an overlay — those produce no events at all.
2. The gesture is terminated mid-press. onPressOut without onPress, at a consistent ~118ms, is React Native's press-cancellation signature: the responder is taken away before the press completes.

So the row never opens because the press on the expense-details screen is cancelled while it is in flight.

What cancels it is the screen underneath. The covered ReportScreen keeps its keyboard-avoiding view enabled, because the flag it uses is a report-ID comparison, not a check of whether the screen actually has navigation focus:

App/src/pages/inbox/ReportScreen.tsx

Line 84 in 4ff4738

const isTopMostReportId = currentReportIDValue === reportIDFromRoute;

App/src/pages/inbox/ReportScreen.tsx

Line 121 in 4ff4738

shouldEnableKeyboardAvoidingView={isTopMostReportId || isInNarrowPaneModal}

isTopMostReportId stays true while the Description screen is open above it, so the blurred Report screen keeps reacting to keyboard events that belong to the screen on top. When the discard modal dismisses that keyboard, the covered screen reacts, and that is what terminates the press being made on it.

Two further measurements support this and rule out the other theories on this issue:

• Removing the discard modal but keeping the navigation: 6/6 clean.
• Keeping the modal but deleting the blocked-navigation replay entirely: 4/4 still broken. So the replayed navigation is not involved, and explanations based on it colliding with the modal teardown don't hold.

Reproduction note, because results here have disagreed: this only reproduces when the expense is opened by drilling in from the chat (chat → expense preview → transaction thread), 5 of 6 attempts. Opening the transaction thread directly from the LHN never reproduces it — 0 of 11. That is the path that leaves a ReportScreen mounted underneath. It is also intermittent (~80%), so one passing run doesn't demonstrate a fix.

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

Require real navigation focus before the Report screen's keyboard-avoiding view is enabled, so a covered screen stops reacting to a keyboard that belongs to the screen above it. In ReportScreen:

const isFocused = useIsFocused();
shouldEnableKeyboardAvoidingView={isFocused && (isTopMostReportId || isInNarrowPaneModal)}

Verified on an iOS simulator, interleaved runs on one harness:

Build	Result	Handler sequence
main	5/6 taps swallowed	onPressIn → onPressOut, no onPress
With this change	0/6 swallowed	onPressIn → onPress → onPressOut

The press completes again, which is the direct confirmation that this addresses the cancellation rather than masking it.

Scoping it to ReportScreen rather than the shared ScreenWrapper keeps unrelated screens' keyboard behaviour untouched.

What alternative solutions did you explore? (Optional)

I implemented and tested these on the reproduction above, 6 cycles each, confirming each build was live before measuring. All still reproduced:

1. Deferring onVisibilityChange(false) until after confirm
2. Blurring the input instead of toggling editable
3. Passing the real dirty state to usePreventRemove and replaying after preventRemove commits false — this was my own earlier root cause, and it is wrong
4. Forcing goBack() instead of re-dispatching the blocked navigation
5. Removing FreezeWrapper's stale-modal gate
6. Deferring the replay via InteractionManager
7. isConfirmLoading, so confirm resolves at press, the pop replays, then the modal closes

(6) and (7) bracket the timing question from both directions — deferring the navigation and advancing it both fail — which is what ruled out the discard-flow ordering family for me.

fix_97127_ios.mp4

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-29 09:25:02 UTC.

Proposal

What is the root cause of that problem?

The Description row already navigates to the correct edit route, so its press handler and route parameters are not the cause.

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 1238 to 1254 in 55b4e0f

	description={translate('common.description')}
	shouldRenderAsHTML
	title={updatedTransactionDescription ?? transactionDescription}
	interactive={canEdit}
	shouldShowRightIcon={canEdit}
	titleStyle={styles.flex1}
	onPress={() => {
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DESCRIPTION.getRoute(
	CONST.IOU.ACTION.EDIT,
	iouType,
	transaction.transactionID,
	transactionThreadReport?.reportID,
	getReportRHPActiveRoute(),
	),
	);
	}}

The problem is the native discard hook's input cleanup. The Description page makes its auto-focused TextInput non-editable while the discard modal is visible, but the hook calls onVisibilityChange(false) for both Cancel and Discard before it branches on the chosen action and before it replays the blocked navigation. On Discard, this unnecessarily re-enables the outgoing input during the short interval between the modal closing and the editor route being popped. iOS can restore first-responder state during that interval; when the editor is then removed, the focus/keyboard transition reaches the underlying report composer. The next Description tap therefore raises the composer instead of opening the editor.

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

Lines 176 to 186 in 55b4e0f

	useDiscardChangesConfirmation({
	onCancel: () => {
	inputRef.current?.focus();
	},
	getHasUnsavedChanges: () => {
	if (isSaved) {
	return false;
	}
	return currentDescription !== currentDescriptionInMarkdown;
	},
	onVisibilityChange: setIsDiscardModalVisible,

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

Lines 208 to 224 in 55b4e0f

	<InputWrapper
	valueType="string"
	InputComponent={TextInput}
	inputID={INPUT_IDS.MONEY_REQUEST_COMMENT}
	name={INPUT_IDS.MONEY_REQUEST_COMMENT}
	defaultValue={currentDescriptionInMarkdown}
	onValueChange={updateDescriptionRef}
	label={translate('moneyRequestConfirmationList.whatsItFor')}
	accessibilityLabel={translate('moneyRequestConfirmationList.whatsItFor')}
	role={CONST.ROLE.PRESENTATION}
	editable={!isDiscardModalVisible}
	autoGrowHeight
	maxAutoGrowHeight={variables.textInputAutoGrowMaxHeight}
	shouldSubmitForm
	type="markdown"
	excludedMarkdownStyles={!isReportInGroupPolicy ? ['mentionReport'] : []}
	ref={inputCallbackRef}

App/src/hooks/useDiscardChangesConfirmation/index.native.ts

Lines 45 to 69 in 55b4e0f

	const showDiscardModal = (blockedAction?: NavigationAction) => {
	blockedNavigationAction.current = blockedAction;
	isDiscardModalOpen.current = true;
	onVisibilityChange?.(true);
	showConfirmModal(getDiscardChangesModalConfig(translate)).then((result) => {
	isDiscardModalOpen.current = false;
	onVisibilityChange?.(false);
	if (result.action !== ModalActions.CONFIRM) {
	blockedNavigationAction.current = undefined;
	onCancel?.();
	return;
	}
	const confirmNavigation = () => {
	isReplayingBlockedNavigation.current = true;
	if (blockedNavigationAction.current) {
	navigationRef.current?.dispatch(blockedNavigationAction.current);
	blockedNavigationAction.current = undefined;
	} else {
	navigationRef.current?.goBack();
	}
	isReplayingBlockedNavigation.current = false;
	};
	runDiscardConfirmation(onConfirm, confirmNavigation, () => {
	blockedNavigationAction.current = undefined;
	});

This behavior came from PR #82097, which added the modal-visibility-controlled editable state to both Description and Merchant to keep the iOS discard modal above the keyboard, without separating Cancel cleanup from confirmed navigation.

bb3ab74

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

Update the native useDiscardChangesConfirmation producer so it clears modal visibility immediately only for Cancel. For confirmed discard, keep the guarded input disabled while onConfirm runs and while the blocked action or hardware Back is replayed; the outgoing screen will then unmount without becoming first responder again. If onConfirm rejects and navigation is aborted, restore the visibility state and run the cancel/refocus cleanup so the mounted form remains usable.

Keep the fix in the shared hook rather than suppressing Description navigation. Description can be opened from expense details, the confirmation list, and split-expense editing, and Merchant uses the same visibility/editable pattern, so a screen-specific workaround would leave equivalent paths exposed.

App/src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx

Lines 139 to 160 in 55b4e0f

	<MenuItemWithTopDescription
	shouldShowRightIcon={!isReadOnly}
	shouldParseTitle
	excludedMarkdownRules={!policy ? ['reportMentions'] : []}
	title={iouComment}
	description={translate('common.description')}
	onPress={() => {
	if (!transactionID) {
	return;
	}
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DESCRIPTION.getRoute(action, iouType, transactionID, reportID, Navigation.getActiveRoute(), reportActionID),
	);
	}}
	style={[styles.moneyRequestMenuItem]}
	titleStyle={styles.flex1}
	disabled={didConfirm}
	interactive={!isReadOnly}
	numberOfLinesTitle={2}
	rightLabel={isDescriptionRequired ? translate('common.required') : ''}
	sentryLabel={CONST.SENTRY_LABEL.REQUEST_CONFIRMATION_LIST.DESCRIPTION_FIELD}

App/src/pages/iou/SplitExpenseEditPage.tsx

Lines 307 to 327 in 55b4e0f

	<MenuItemWithTopDescription
	shouldShowRightIcon
	shouldRenderAsHTML
	key={translate('common.description')}
	description={translate('common.description')}
	title={currentDescription}
	onPress={() => {
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DESCRIPTION.getRoute(
	CONST.IOU.ACTION.EDIT,
	CONST.IOU.TYPE.SPLIT_EXPENSE,
	CONST.IOU.OPTIMISTIC_TRANSACTION_ID,
	reportID,
	Navigation.getActiveRoute(),
	),
	);
	}}
	style={[styles.moneyRequestMenuItem]}
	titleWrapperStyle={styles.flex1}
	numberOfLinesTitle={2}
	rightLabel={isDescriptionRequired ? translate('common.required') : ''}

Test coverage:

• Extend tests/unit/hooks/useDiscardChangesConfirmationNative.test.ts for both blocked-action and hardware-Back paths: opening emits visibility true, Cancel emits false and refocuses, successful Confirm navigates without re-enabling the outgoing input first, and a rejected onConfirm restores the mounted form without navigating.
• Preserve the existing exact-once replay assertions and verify onConfirm still finishes before navigation.
• On iOS, exercise Description from expense details, the confirmation list, and split-expense editing, plus the analogous Merchant field: edit, Back, Discard changes, immediately reopen, and verify the editor opens while the report composer remains unfocused.

What alternative solutions did you explore? (Optional)

Suppressing native focus-return only in IOURequestStepDescription does not address this ordinary input/keyboard handoff and leaves Merchant exposed. Changing the Description row is also inappropriate because its route is already correct.

I also considered deferring the replayed navigation until a later microtask/frame so it cannot overlap the global modal teardown. That may be useful if device logging proves a separate native presentation race, but by itself it leaves the outgoing input re-enabled for an even longer interval. The shared hook should first stop writing that invalid editability state while preserving explicit refocus behavior when the user cancels.

[lorretheboy]

Proposal

What is the root cause of that problem?

The native useDiscardChangesConfirmation replays the blocked back-navigation the moment the confirm-modal promise resolves:

App/src/hooks/useDiscardChangesConfirmation/index.native.ts

Lines 57 to 70 in 6b9a8c6

	const confirmNavigation = () => {
	isReplayingBlockedNavigation.current = true;
	if (blockedNavigationAction.current) {
	navigationRef.current?.dispatch(blockedNavigationAction.current);
	blockedNavigationAction.current = undefined;
	} else {
	navigationRef.current?.goBack();
	}
	isReplayingBlockedNavigation.current = false;
	};
	runDiscardConfirmation(onConfirm, confirmNavigation, () => {
	blockedNavigationAction.current = undefined;
	});
	});

That promise resolves from ConfirmModalWrapper.handleModalHide → closeModal, and on iOS onModalHide is fired from RN Modal's native onDismiss callback (Android deliberately calls it earlier, from the JS animation callback — this is why only iOS breaks):

App/src/components/Modal/ReanimatedModal/index.tsx

Lines 247 to 252 in 6b9a8c6

	onDismiss={() => {
	onDismiss?.();
	if (getPlatform() !== CONST.PLATFORM.ANDROID) {
	onModalHide();
	}
	}}

So on iOS the GO_BACK that pops the RHP is dispatched from inside the modal's native dismissal callback, while closeModal is unmounting the modal in the same pass. The native-stack pop overlaps the modal teardown, and react-native-screens is left out of sync with react-navigation: the pop shows, but the next PUSH of the RHP is never presented. The JS state does accept that push, so on the second tap the new description screen mounts invisibly and its autofocused input opens the keyboard (the timeout fallback fires even though no transition ran) — that's the reported "composer jumps up":

App/src/hooks/useAutoFocusInput.ts

Lines 105 to 114 in 6b9a8c6

	useFocusEffect(
	useCallback(() => {
	isAutoFocusCancelledRef.current = false;
	setIsScreenTransitionEnded(false);
	transitionEndTimeoutRef.current = setTimeout(() => {
	if (isAutoFocusCancelledRef.current) {
	return;
	}
	setIsScreenTransitionEnded(true);
	}, CONST.SCREEN_TRANSITION_END_TIMEOUT);

And once the JS-focused route is already the description screen, every further tap is silently dropped by the duplicate-route check, so the page never opens:

App/src/libs/Navigation/helpers/linkTo/index.ts

Lines 172 to 175 in 6b9a8c6

	// We don't want to dispatch action to push/replace with exactly the same route that is already focused.
	if (areNamesAndParamsEqual(currentState, stateFromPath) || arePathAndBackToEqual(stateFromPath)) {
	return;
	}

The web variant of the hook already guards against exactly this by deferring the replay with setNavigationActionToMicrotaskQueue (microtask + requestAnimationFrame, i.e. after the modal teardown commits):

App/src/hooks/useDiscardChangesConfirmation/index.ts

Lines 84 to 91 in 6b9a8c6

	runDiscardConfirmation(
	onConfirm,
	() => setNavigationActionToMicrotaskQueue(navigateBack),
	() => {
	blockedNavigationAction.current = undefined;
	shouldNavigateBack.current = false;
	},
	);

The native hook has no such deferral — that's the bug.

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

In useDiscardChangesConfirmation/index.native.ts, defer the replay out of the modal-dismissal callstack, mirroring the web hook — pass the navigation through the existing setNavigationActionToMicrotaskQueue helper (or InteractionManager.runAfterInteractions) instead of dispatching directly:

runDiscardConfirmation(onConfirm, () => setNavigationActionToMicrotaskQueue(confirmNavigation), () => {
    blockedNavigationAction.current = undefined;
});

Because the fix is in the shared hook, it covers every screen that uses it (description, merchant, amount, distance, hours, agent rules), not just the description page.

What alternative solutions did you explore? (Optional)

Making ReanimatedModal call onModalHide from the JS close callback on iOS as it already does on Android would remove the problematic timing at its source, but it changes hide-timing for every modal in the app, so the narrowly-scoped deferral in the discard hook is safer.