[Due for payment 2026-07-16] [$250] iOS - PR94474 - Expense-Input field loses focus after dismissing the "Discard changes" modal

[applause-bot]

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: 9.4.26-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: #94474
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 13 iOS 26.5
App Component: Money Requests

Action Performed:

1. Open tne app
2. Tap the FAB button and select "Track distance".
3. Switch to the Odometer tab.
4. Type any value into one of the input fields and keep it focused.
5. While the input is still focused, swipe back or tap the back button, a "Discard changes" confirmation modal should appear.
6. Tap "Cancel" to dismiss the modal.

Expected Result:

The focus returns to the input field after the modal closes.

Actual Result:

Input field loses focus after dismissing the "Discard changes" modal when swiping back

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197044_1782947548439.ScreenRecording_07-01-2026_18-04-55_1.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7197044

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072568867072843192
• Upwork Job ID: 2072568867072843192
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @mallenexpensify

[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/20bffdb2aaf394006a35ef029c5010ef94796ec04d21f9ea1a5fda7509405c7d

[MelvinBot]

Proposal

What is the root cause of that problem?

This is a regression from #94474 ("Migrate InteractionManager - (Newly added usages) part 2"), merged 2026-06-30.

Before that PR, restoreLastInputFocus in the Odometer step deferred the re-focus until after the modal dismiss/navigation animation settled:

const restoreLastInputFocus = useCallback(() => {
    InteractionManager.runAfterInteractions(() => {
        lastFocusedInputRef.current?.focus();
    });
}, []);

The PR removed the deferral entirely instead of migrating it to TransitionTracker (which is exactly what it did for the sibling odometer change in useReportSelectionActions.ts). The focus call is now synchronous:

Current code (regressed)

src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx:514-516

const restoreLastInputFocus = useCallback(() => {
    lastFocusedInputRef.current?.focus();
}, []);

restoreLastInputFocus is wired to the discard modal's onCancel (line 520), and onCancel?.() is invoked synchronously the moment the modal resolves as Cancel in useDiscardChangesConfirmation.

When the modal is triggered by a swipe-back / hardware back gesture, a navigation transition is in flight. The now-synchronous focus() fires while the discard modal is still animating out (and the back transition is settling), so the OS/native layer drops the focus and the keyboard closes. The overlay-tap path has no navigation transition in flight, which is why the PR's own QA step ("tap the overlay behind the form") passed while the swipe/back path regressed.

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

Restore the deferral, but using the new TransitionTracker API (consistent with the rest of PR #94474's migration) rather than the deprecated InteractionManager. Because navigation may be starting just before this runs (swipe/back), use waitForUpcomingTransition: true so the focus is queued to run after the transition ends — the same pattern the PR applied to useReportSelectionActions.ts:

const restoreLastInputFocus = useCallback(() => {
    TransitionTracker.runAfterTransitions({
        waitForUpcomingTransition: true,
        callback: () => {
            lastFocusedInputRef.current?.focus();
        },
    });
}, []);

(plus import TransitionTracker from '@libs/Navigation/TransitionTracker';)

What alternative solutions did you explore? (Optional)

• Re-adding InteractionManager.runAfterInteractions would fix it but reverts the intent of Migrate InteractionManager - (Newly added usages) part 2 #94474 and re-introduces a deprecated API (tracked by [Partial Payment x 3][Tracking] Deprecation of InteractionManager #71913).
• A raw setTimeout/microtask defer would be flakier than TransitionTracker, which is transition-aware.

---

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

[kitvasyl]

Proposal

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

After canceling the discard-changes modal on the odometer distance screen, the previously focused reading input does not regain focus on native platforms.

What is the root cause of that problem?

In src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx, showing the modal sets the inputs' editable prop to false, which blurs the native input. The cancel handler restores focus with InteractionManager.runAfterInteractions(), but that only waits for React Native interactions and does not guarantee that the modal has fully closed and the native window is ready to accept focus. The focus call can therefore be ignored.

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

Replace the cancel handler's direct InteractionManager scheduling with the existing focusAfterModalClose() helper from src/libs/focusAfterModalClose.ts, passing lastFocusedInputRef.current. This helper waits for both the composer focus lock and the native window to become focusable before calling focus(). If necessary, widen its parameter type from TextInput to a minimal focusable-ref type so it accepts BaseTextInputRef without a cast. Remove the now-unused InteractionManager import.

What alternative solutions did you explore? (Optional)

Keeping the inputs editable while the modal is visible would avoid the blur, but it could allow changes behind the modal. A fixed timeout would remain timing-dependent, so using the existing modal-close focus coordination is safer.

[shivang-goliyan]

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

Proposal

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

On iOS and Android, when you start tracking distance by odometer, type into one of the reading fields, and then try to leave, a "Discard changes" modal pops up. Tapping "Cancel" is supposed to keep you on the screen with your text and the keyboard still there. Instead the input loses focus the moment the modal closes, so the keyboard drops and you have to tap the field again.

What is the root cause of that problem?

The bug is in restoreLastInputFocus at src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx (lines 514-516). This callback is passed as onCancel to useDiscardChangesConfirmation, and its job is to put focus back on the last input once you dismiss the modal.

const restoreLastInputFocus = useCallback(() => {
    lastFocusedInputRef.current?.focus();
}, []);

The .focus() call is now firing too early. In useDiscardChangesConfirmationNative.ts, onCancel?.() runs inside the .then() of showConfirmModal, which resolves synchronously the instant the Global modal promise resolves (ModalContext.closeModal calls lastModalPromise.resolve right away). So .focus() runs while the modal is still animating out. On native, the dismissing modal then blurs the input right after our synchronous focus, and focus is lost. On web this doesn't happen because focusing a DOM input synchronously is fine, which is why it only reproduces on iOS App and Android App.

This is a regression. PR #94474 (merged 2026-06-30, "Migrate InteractionManager - part 2") stripped the InteractionManager.runAfterInteractions wrapper that used to defer the focus until after the modal animation finished. That deferral was added on purpose by #87269 when this discard flow was first built. The bug report is dated two days after #94474 merged, and #94474 is exactly the PR the QA team tagged as the source.

One thing worth calling out, since it looks like an easy alternative: swapping in TransitionTracker.runAfterTransitions will not fix this. TransitionTracker only waits on navigation screen transitions, and the Cancel path does no navigation, it just closes a component-level Global modal. With no active transitions, TransitionTracker.ts runs the callback synchronously (lines 148-151), so you'd be right back where you started. The wait here has to be on a component animation, which is what InteractionManager gives you.

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

Restore the deferral that #94474 removed. Re-add the InteractionManager import to the react-native import on line 4 (with its no-restricted-imports eslint-disable) and wrap the focus call:

const restoreLastInputFocus = useCallback(() => {
    InteractionManager.runAfterInteractions(() => {
        lastFocusedInputRef.current?.focus();
    });
}, []);

This restores the exact behavior verbatim, no broadening, so the input regains focus only after the modal's dismiss animation settles. I'd also add a test to useDiscardChangesConfirmationNative.test.ts (around lines 182-188 it currently checks that onCancel fires but not that the refocus is deferred) mocking InteractionManager to assert the focus runs after interactions, so this doesn't silently regress again.

What alternative solutions did you explore? (Optional)

Migrating to TransitionTracker.runAfterTransitions, which is the direction #94474 was moving in generally. As explained above, it no-ops synchronously when there's no navigation transition, so it doesn't solve this case. I also considered a requestAnimationFrame or setTimeout deferral, but those are guesses at the animation duration and STYLE.md discourages setTimeout as a timing band-aid. InteractionManager.runAfterInteractions is the mechanism already proven correct here by #87269, so restoring it is the minimal, behavior-matching fix.

[lorretheboy]

Proposal

What is the root cause of that problem?

PR #94474 removed the InteractionManager.runAfterInteractions deferral around the odometer step's focus restore, leaving a synchronous focus() call:

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

Lines 514 to 516 in 5df38e8

	const restoreLastInputFocus = useCallback(() => {
	lastFocusedInputRef.current?.focus();
	}, []);

When "Cancel" is tapped, the hook resolves and runs onVisibilityChange?.(false) followed immediately (same tick) by onCancel?.():

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

Lines 45 to 51 in 5df38e8

	showConfirmModal(getDiscardChangesModalConfig(translate)).then((result) => {
	isDiscardModalOpen.current = false;
	onVisibilityChange?.(false);
	if (result.action !== ModalActions.CONFIRM) {
	blockedNavigationAction.current = undefined;
	onCancel?.();
	return;

The causal chain: onVisibilityChange(false) only queues the setIsDiscardModalVisible(false) state update → onCancel() then calls focus() synchronously, before React re-renders → at that moment the odometer inputs are still committed with editable={false}, because they are disabled while the discard modal is up:

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

Line 587 in 5df38e8

editable={!isDiscardModalVisible}

On iOS/Android, focus() on a non-editable TextInput is ignored by the native side. When the re-render finally makes the input editable again, nothing re-triggers focus, so it stays blurred. Before PR #94474, runAfterInteractions deferred the focus() to a later task, after the re-render made the input editable, so it worked.

This is specific to the odometer step — the sibling steps (Amount, Hours, DistanceManual) already defer their focus restore and don't gate editable on modal visibility.

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

Restore focus only after the input is actually editable again, instead of synchronously in onCancel. In IOURequestStepDistanceOdometer, have onCancel just set a flag, and do the focus in an effect that fires when isDiscardModalVisible flips back to false (i.e., after the re-render that re-enables the inputs):

const shouldRestoreFocusRef = useRef(false);

useEffect(() => {
    if (isDiscardModalVisible || !shouldRestoreFocusRef.current) {
        return;
    }
    shouldRestoreFocusRef.current = false;
    lastFocusedInputRef.current?.focus();
}, [isDiscardModalVisible]);

and pass onCancel: () => { shouldRestoreFocusRef.current = true; } here:

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

Lines 518 to 520 in 5df38e8

	useDiscardChangesConfirmation({
	getHasUnsavedChanges,
	onCancel: restoreLastInputFocus,

This is deterministic — it keys off the exact condition that made the focus call a no-op (editable={!isDiscardModalVisible}) rather than off a timing guess.

What alternative solutions did you explore? (Optional)

Match the sibling steps' pattern and defer with setTimeout(() => lastFocusedInputRef.current?.focus(), CONST.ANIMATED_TRANSITION) inside restoreLastInputFocus (as IOURequestStepAmount/IOURequestStepDistanceManual do). Simpler, but timing-based rather than tied to the editable state that actually blocks the focus.

[aswin-s]

Proposal

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

On iOS (and Android), when a user types a value into an Odometer reading input on the Track Distance flow, swipes back to trigger the "Discard changes" confirmation modal, and taps Cancel to dismiss it, the input field does not regain focus and the keyboard does not reappear. The expected behavior is that focus returns to the previously focused input after the modal closes.

What is the root cause of that problem?

In src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx:514-520, restoreLastInputFocus (wired to useDiscardChangesConfirmation's onCancel) calls lastFocusedInputRef.current?.focus() synchronously right after the modal resolves. In src/hooks/useDiscardChangesConfirmation/index.native.ts:45-51, the modal-resolved callback runs onVisibilityChange?.(false) (which schedules setIsDiscardModalVisible(false)) and then immediately invokes onCancel?.() in the same tick. The setState has not flushed yet, so the two TextInputs at lines 587 and 633 are still rendered with editable={!isDiscardModalVisible} = editable={false}. Calling .focus() on a non-editable iOS TextInput is a no-op, and by the time the re-render sets editable={true} there is no pending focus request, so the field remains blurred.

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

1. src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx:514-516 — defer the focus call so it runs after React has committed isDiscardModalVisible = false and the inputs are editable again (e.g. wrap lastFocusedInputRef.current?.focus() in InteractionManager.runAfterInteractions / a requestAnimationFrame, or use a small setTimeout(0)), so .focus() targets an editable input.
2. Alternatively, in src/hooks/useDiscardChangesConfirmation/index.native.ts:45-51, invoke onCancel?.() inside a microtask/queueMicrotask (or after a Promise.resolve().then(...)) so that the onVisibilityChange(false) state update commits before consumer restore-focus logic runs — this fixes any current or future consumers, not just Odometer.
3. As a belt-and-braces fix on the Odometer page, stop gating editable on isDiscardModalVisible (lines 587, 633) — the modal already blocks input, and disabling the field is what prevents the refocus from taking effect.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[abbasifaizan70]

Proposal

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

On the "Track distance" > Odometer tab, if a user types into a reading input and then swipes back (or taps the back button) while the input is still focused, the "Discard changes" confirmation modal appears. Tapping "Cancel" dismisses the modal, but the previously-focused input does not regain focus, even though it did before PR #94474.

What is the root cause of that problem?

IOURequestStepDistanceOdometer remembers the last-focused reading input in lastFocusedInputRef and, on "Cancel", calls restoreLastInputFocus, which just calls .focus() on that ref synchronously as the onCancel callback of useDiscardChangesConfirmation:

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

Lines 514 to 520 in f61c657

	const restoreLastInputFocus = useCallback(() => {
	lastFocusedInputRef.current?.focus();
	}, []);
	useDiscardChangesConfirmation({
	getHasUnsavedChanges,
	onCancel: restoreLastInputFocus,

Before PR #94474 ("Migrate InteractionManager - part 2"), this .focus() call was wrapped in InteractionManager.runAfterInteractions(...). That wrapper made the focus call wait until the confirm modal's underlying close transition had actually finished, because the modal itself holds an InteractionManager interaction handle for the entire duration of its hide animation. The handle is created the moment the modal starts closing and is only cleared once the close animation callback fires:

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

Lines 122 to 167 in f61c657

	useEffect(() => {
	if (isVisible && !isContainerOpen && !isTransitioning) {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillShow();
	// eslint-disable-next-line react-hooks/set-state-in-effect
	setIsVisibleState(true);
	setIsTransitioning(true);
	} else if (!isVisible && isContainerOpen && !isTransitioning) {
	handleRef.current = InteractionManager.createInteractionHandle();
	transitionHandleRef.current = TransitionTracker.startTransition();
	onModalWillHide();
	blurActiveElement();
	setIsVisibleState(false);
	setIsTransitioning(true);
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [isVisible, isContainerOpen, isTransitioning]);
	const backdropStyle: ViewStyle = useMemo(() => {
	return {width: windowWidth, height: windowHeight, backgroundColor: backdropColor};
	}, [windowWidth, windowHeight, backdropColor]);
	const onOpenCallBack = useCallback(() => {
	setIsTransitioning(false);
	setIsContainerOpen(true);
	if (handleRef.current) {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.clearInteractionHandle(handleRef.current);
	}
	if (transitionHandleRef.current) {
	TransitionTracker.endTransition(transitionHandleRef.current);
	transitionHandleRef.current = null;
	}
	onModalShow();
	}, [onModalShow]);
	const onCloseCallBack = useCallback(() => {
	setIsTransitioning(false);
	setIsContainerOpen(false);
	if (handleRef.current) {
	InteractionManager.clearInteractionHandle(handleRef.current);
	}

Because restoreLastInputFocus no longer defers via InteractionManager.runAfterInteractions, .focus() now runs immediately when the "Cancel" button's promise resolves — while the confirm modal (and its native overlay/presentation) is still mid dismiss-animation. On iOS in particular, a TextInput cannot become the first responder while a native modal is still presented/animating away, so this early .focus() call is silently dropped, and once the modal actually finishes closing nothing re-triggers the focus, leaving the input blurred.

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

Re-defer restoreLastInputFocus so it only runs once the confirm modal's hide interaction (and therefore its close animation) has actually completed, using InteractionManager.runAfterInteractions exactly as it did before the migration:

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

Lines 514 to 516 in f61c657

	const restoreLastInputFocus = useCallback(() => {
	lastFocusedInputRef.current?.focus();
	}, []);

const restoreLastInputFocus = useCallback(() => {
  InteractionManager.runAfterInteractions(() => {
    lastFocusedInputRef.current?.focus();
  });
}, []);

And restore the corresponding import of InteractionManager from react-native in this file (it was removed as part of the same migration).

[melvin-bot]

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