[$250] Distance - The map is cropped after editing the odometer

[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.27-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #95039
Email or phone of affected tester (no customers): sustinov@applausemail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 12 PRO/iOS 26.3
App Component: Money Requests

Action Performed:

Prerequisites:
Use an HT account in an existing WS

Steps:

1. Open ND app
2. Open FAB > Track distance > Odometer
3. Enter start and end reading > Save for later
4. Open FAB > Track distance > Odometer
5. Edit any value
6. Tap on the “Map” tab
7. Tap "Discard changes"

Expected Result:

The map should be fully visible in the window after editing the odometer

Actual Result:

The map is cropped after the odometer is edited

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7199621_1783187440712.ScreenRecording_07-04-2026_22-27-51_1.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074082196836542899
• Upwork Job ID: 2074082196836542899
• Last Price Increase: 2026-07-06

[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/3fb89f8f4873d8b13cf72633d3eb01737c51257e83937fe8e3c8d6f96697715e

[MelvinBot]

Proposal

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

On iOS, the distance-request Map tab renders cropped (not full height) after a user edits an odometer reading and taps "Discard changes" to switch to the Map tab.

What is the root cause of that problem?

All distance tabs (Odometer / Map / Manual) share one ScreenWrapper in DistanceRequestStartPage.tsx:115, whose KeyboardAvoidingView is enabled only while the Odometer tab is selected:

shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}

When you edit an odometer field the keyboard is up, so the iOS KeyboardAvoidingView shrinks the shared container. Tapping Map triggers the unsaved-changes discard guard, and on Discard the navigator does TabActions.jumpTo(Map) and lazily mounts the Map tab while the container is still keyboard-shrunk — the tab navigator uses keyboardDismissMode="none", so the keyboard/KAV state hasn't collapsed yet.

The map itself has no measured/pixel height — it's flex: 1 + minHeight: 300 with overflow: 'hidden'. So it lays out into the reduced height at mount and never re-measures once the keyboard closes and the KAV disables → it stays cropped.

Evidence & data flow

• Shared wrapper gated on tab: DistanceRequestStartPage.tsx:114-115
• iOS KAV physically resizes to keyboard: BaseKeyboardAvoidingView/index.ios.tsx (uses react-native-keyboard-controller) — explains why the repro is iOS-specific.
• Discard → jumpTo without dismissing keyboard, lazy mount: OnyxTabNavigator.tsx and keyboardDismissMode="none" at OnyxTabNavigator.tsx:243.
• Discard handler resets odometer data only, nothing about layout/keyboard: IOURequestStepDistanceOdometer.tsx:513.
• Map is flex-only, no captured height: mapViewContainer (flex1 + minHeight:300) / mapView (flex1, overflow:'hidden') in src/styles/index.ts.

Flow: odometer keyboard up → KAV shrinks shared container → tap Map → discard guard → jumpTo(Map) lazy-mounts Map inside the still-shrunk container → map lays out short → keyboard closes but map never re-measures → cropped.

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

Ensure the shared container is at full height before the Map tab mounts, or force the map to re-measure after the switch. Options, cheapest first:

1. Dismiss the keyboard before jumping tabs on discard so the KAV collapses before the Map tab lazy-mounts (e.g. call Keyboard.dismiss() in the discard path in OnyxTabNavigator.tsx / the odometer discard handler, and let the KAV settle before jumpTo).
2. Force the map to re-layout on tab change — key the map container on selectedTab, or trigger a remeasure when the Map tab gains focus, so it re-reads the (now full) container height.

⚠️ Confidence: Medium. Root cause is confirmed by code, but the exact iOS timing (KAV still enabled via async selectedTab vs. residual keyboard height at mount) should be confirmed with an on-device repro before locking in option 1 vs 2.

What alternative solutions did you explore?

The bug is not a stale onLayout pixel-height snapshot (the initial hypothesis) — the map captures no height; it's cross-tab container-height contamination. A remeasure/remount of the map is the reliable fallback if the keyboard-dismiss timing proves flaky.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95376) 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 editing a saved odometer draft and switching to the Map tab, confirming “Discard changes” displays the map cropped on iOS.

What is the root cause of that problem?

In src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx, the focused odometer TextInput opens the keyboard. The useDiscardChangesConfirmation flow allows the pending tab navigation to continue after confirmation without dismissing that keyboard, so the map mounts using the keyboard-reduced viewport.

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

Update IOURequestStepDistanceOdometer to call Keyboard.dismiss() when the discard confirmation becomes visible (while retaining setIsDiscardModalVisible). This ensures the viewport is restored before the confirmed navigation displays the Map tab. Keep the existing onCancel behavior that refocuses the last input if the user chooses to remain on the odometer screen.

What alternative solutions did you explore? (Optional)

Dismissing the keyboard inside the map screen would mask the stale state, but the odometer screen that owns the focused input should clean it up before navigation.

[abbasifaizan70]

Proposal

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

On the Odometer distance tab, if the user edits an odometer reading (opening the keyboard), then taps the "Map" tab and confirms "Discard changes" in the resulting modal, the Map tab renders with its bottom portion cropped/covered instead of filling the available space.

What is the root cause of that problem?

DistanceRequestStartPage wraps all four distance tabs (Map, Manual, GPS, Odometer) in a single ScreenWrapper/KeyboardAvoidingView, and only enables keyboard avoidance while the Odometer tab is selected:

App/src/pages/iou/request/DistanceRequestStartPage.tsx

Lines 114 to 119 in fec6b33

	<ScreenWrapper
	shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}
	shouldEnableMinHeight={canUseTouchScreen()}
	testID="DistanceRequestStartPage"
	focusTrapSettings={{containerElements: focusTrapContainerElements}}
	>

The tab navigator that hosts these tabs explicitly disables keyboard dismissal on tab switch, so focus (and the native keyboard) stays exactly as it was when the user taps another tab:

App/src/libs/Navigation/OnyxTabNavigator.tsx

Lines 241 to 244 in fec6b33

	initialRouteName={validInitialTab}
	backBehavior={backBehavior}
	keyboardDismissMode="none"
	tabBar={TabBarWithFocusTrapInclusion}

When the discard-changes modal is confirmed after editing an odometer reading, handleTabSwitchDiscard only clears the odometer reading/image state — it never blurs the still-focused reading input or dismisses the keyboard — before the navigator jumps to the Map tab:

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

Lines 513 to 521 in fec6b33

	const handleTabSwitchDiscard = () => {
	setMoneyRequestOdometerReading(transactionID, null, null, isTransactionDraft);
	removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.START, isTransactionDraft, true);
	removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.END, isTransactionDraft, true);
	// Clear typing guard so draft re-hydration can resync readings into the inputs on return.
	userHasUnsavedTypingRef.current = false;
	resetOdometerLocalState();
	setFormError('');
	};

Because the Odometer TextInput is still focused and keyboardDismissMode="none" prevents the keyboard from closing on its own, the native keyboard remains visible after the jump to Map. But selectedTab has already flipped to distance-map, so shouldEnableKeyboardAvoidingView becomes false for the shared KeyboardAvoidingView. With avoidance disabled, the Map tab's container no longer shrinks to make room for the still-open keyboard, so the keyboard visually overlaps and crops the bottom of the map.

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

Dismiss the keyboard when the odometer tab-switch discard runs, so the keyboard is actually closed by the time the Map tab (with keyboard avoidance disabled) becomes active, matching the shouldEnableKeyboardAvoidingView state to the real keyboard state.

import {useIsFocused} from '@react-navigation/native';
import lodashIsEmpty from 'lodash/isEmpty';
import React, {useCallback, useEffect, useMemo, useRef, useState} from 'react';
import {Keyboard, View} from 'react-native';

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

Lines 513 to 521 in fec6b33

	const handleTabSwitchDiscard = () => {
	setMoneyRequestOdometerReading(transactionID, null, null, isTransactionDraft);
	removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.START, isTransactionDraft, true);
	removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.END, isTransactionDraft, true);
	// Clear typing guard so draft re-hydration can resync readings into the inputs on return.
	userHasUnsavedTypingRef.current = false;
	resetOdometerLocalState();
	setFormError('');
	};

    const handleTabSwitchDiscard = () => {
        Keyboard.dismiss();
        setMoneyRequestOdometerReading(transactionID, null, null, isTransactionDraft);

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 10:51:50 UTC.

Proposal

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

On iOS, after editing odometer readings on the Odometer tab and switching to the Map tab via "Discard changes", the map preview renders cropped (smaller than the available space) instead of filling its container. The bug is a regression introduced by PR #95039 which added the discard-confirmation flow to IOURequestStepDistanceOdometer.

What is the root cause of that problem?

The root cause is a layout-race specific to iOS triggered by three interacting mechanisms in the Odometer→Map tab-switch discard flow:

1. DistanceRequestStartPage.tsx:115 — keyboard-avoidance is gated on a stale Onyx value

<ScreenWrapper
    shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}

selectedTab is read from Onyx (CONST.TAB.DISTANCE_REQUEST_TYPE). It switches from DISTANCE_ODOMETER to DISTANCE_MAP only after OnyxTabNavigator's state listener fires Tab.setSelectedTab(...) — an asynchronous Onyx write that happens after the React Navigation state has already been updated and the Map tab has been mounted.

2. OnyxTabNavigator.tsx — keyboardDismissMode="none" keeps the keyboard visible

<TopTab.Navigator keyboardDismissMode="none" ...>

The keyboard does not auto-dismiss when the user taps the tab bar. The confirm modal shown by OnyxTabNavigator.handleTabPress is a React Native component modal (not a native UIAlertController), so it also does not dismiss the keyboard on iOS.

3. IOURequestStepDistanceOdometer.tsx:~513 — handleTabSwitchDiscard never dismisses the keyboard

const handleTabSwitchDiscard = () => {
    setMoneyRequestOdometerReading(transactionID, null, null, isTransactionDraft);
    removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.START, isTransactionDraft, true);
    removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.END, isTransactionDraft, true);
    userHasUnsavedTypingRef.current = false;
    resetOdometerLocalState();
    setFormError('');
};

Ordered event timeline that produces the crop:

1. User is editing odometer values → keyboard is visible on screen.
2. User taps "Map" tab → keyboardDismissMode="none" keeps keyboard visible.
3. Confirm modal appears (React Native modal — keyboard remains visible on iOS).
4. User taps "Discard changes" → handleTabSwitchDiscard() runs; keyboard is still visible.
5. navigation.dispatch(TabActions.jumpTo('DISTANCE_MAP')) fires (in the Promise.resolve().then(guard.onDiscard).then(dispatch) chain).
6. Map tab (IOURequestStepDistanceMap) mounts. At this moment:
   • selectedTab in Onyx is still DISTANCE_ODOMETER (Onyx write from step 9 hasn't landed).
   • shouldEnableKeyboardAvoidingView={true} is still active in DistanceRequestStartPage.
   • Keyboard is still visible → the active KeyboardAvoidingView in ScreenWrapper reduces the available height by the keyboard height.
   • The map container (styles.mapViewContainer = {flex: 1, minHeight: 300} in DistanceRequestFooter) measures itself at this keyboard-reduced height.
   • The Mapbox native iOS view latches this initial measured height.
7. Keyboard dismisses (no focused text input on Map tab).
8. Tab.setSelectedTab(id, 'DISTANCE_MAP') Onyx write lands → selectedTab = DISTANCE_MAP → shouldEnableKeyboardAvoidingView=false → ScreenWrapper regains full height.
9. But the Mapbox native iOS view has already latched the reduced measurement and does not re-fit → map appears cropped.

Note: The correct parent component is DistanceRequestStartPage (used in the Track Distance create flow with DISTANCE_MAP/DISTANCE_ODOMETER/DISTANCE_GPS/DISTANCE_MANUAL tabs). This is not IOURequestStepDistance, which is only used in the edit flow and has no shouldEnableKeyboardAvoidingView condition on tab selection.

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

Primary fix — src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx:~513:

Add Keyboard.dismiss() as the first line of handleTabSwitchDiscard. This dismisses the keyboard synchronously before any Onyx writes or navigation, ensuring the map container measures at full screen height when the Map tab mounts:

const handleTabSwitchDiscard = () => {
    Keyboard.dismiss(); // dismiss before navigation so the Map tab mounts with full height
    setMoneyRequestOdometerReading(transactionID, null, null, isTransactionDraft);
    removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.START, isTransactionDraft, true);
    removeMoneyRequestOdometerImage(transaction, CONST.IOU.ODOMETER_IMAGE_TYPE.END, isTransactionDraft, true);
    userHasUnsavedTypingRef.current = false;
    resetOdometerLocalState();
    setFormError('');
};

With this fix: keyboard is gone before guard.onDiscard() returns → when navigation.dispatch(TabActions.jumpTo('DISTANCE_MAP')) fires, the keyboard is already invisible → even though shouldEnableKeyboardAvoidingView is briefly still true (stale Onyx), the KeyboardAvoidingView has no effect because the keyboard height is 0 → map container measures at full height → no cropping.

Secondary safety net (optional, increases robustness) — src/components/DistanceRequest/DistanceRequestFooter.tsx:

The DistanceRequestFooter map container renders DistanceMapView inside a <View style={[styles.mapViewContainer, mapContainerStyle]}> (flex: 1, minHeight: 300). On iOS, the Mapbox native view latches its first-measured height. Adding an onLayout callback that calls fitBounds/setCamera on the map's camera ref when the container dimensions change would make the map self-healing against any future layout races. This is a defensive layer, not the root-cause fix.

Verify no regression on sibling discard flows:

• Manual → Odometer (within DistanceRequestStartPage): no discard guard currently, not affected.
• Map → Odometer and Odometer → GPS: no discard guard currently, not affected.
• IOURequestStepDistance edit flow (Map ↔ Manual): uses a separate OnyxTabNavigator with CONST.TAB.DISTANCE_EDIT_TYPE; IOURequestStepDistance's useDiscardChangesConfirmation has no onTabSwitchDiscard handler, so this flow is not affected.

What alternative solutions did you explore?

• Dispatch the tab jump first, then run onDiscard: Would flip the order in OnyxTabNavigator.handleTabPress, so the Map tab renders before the odometer state is cleared. This is a UX regression — the user would briefly see the odometer data still present on the Map tab while handleTabSwitchDiscard clears it, and it doesn't fix the keyboard-avoidance race.
• Defer the Onyx writes in handleTabSwitchDiscard (e.g., wrap in InteractionManager.runAfterInteractions): The keyboard would still be visible when the Map tab mounts, so the crop would persist.
• Remove keyboardDismissMode="none" from OnyxTabNavigator: Too broad a change; keyboardDismissMode="none" is the intentional behavior for other tab navigators that shouldn't auto-dismiss the keyboard on tab switch.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 10:54:59 UTC.

Proposal

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

On iOS, if you start a distance expense with the Odometer tab, save it, then reopen it and edit a reading, switching over to the Map tab and tapping "Discard changes" leaves the map cropped instead of filling the window. It only happens after the odometer has been edited, and only in the native iOS app.

What is the root cause of that problem?

In the create flow (FAB > Track distance), all three tabs share a single ScreenWrapper in src/pages/iou/request/DistanceRequestStartPage.tsx. Each tab's own StepScreenWrapper is skipped here because shouldShowWrapper={!isCreatingNewRequest} is false during creation, so this shared wrapper holds the one and only KeyboardAvoidingView for the whole navigator.

That KAV is turned on for just the Odometer tab:

shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}

The Map tab stays mounted the whole time (it's the default tab), and its mapViewContainer is {flex: 1, minHeight: 300}. When you edit an odometer reading the keyboard opens and the shared KAV shrinks the shared container, which is also hosting that still-mounted map. Then you switch to Map and hit "Discard changes", which flips enabled from true back to false on that same KAV right as the keyboard is dismissing. On iOS the container and the underlying Mapbox view don't reclaim the full height, so the map renders at the shrunken size. This isn't a data problem (Discard clears the readings, but the symptom is the map's size, not its values), and it isn't the linked PR #95039, which only touched odometer reading logic and a hook test. The enabled toggle came in with 1a271c6 ("Fix: Enable keyboard avoiding view for Odometer tab"), where the shared wrapper went from ={false} to being tab-conditional. It fixed the odometer's own keyboard handling but tied the map-hosting container's height to the odometer keyboard.

One caveat: this is a native layout/timing bug, so I've flagged the fix location as the best-supported hypothesis and it needs an iOS build to confirm before we commit to it.

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

Stop letting the odometer keyboard drive the shared container. Set the shared ScreenWrapper back to shouldEnableKeyboardAvoidingView={false} (its value before 1a271c6), and give the Odometer tab its own KeyboardAvoidingView wrapping just its input View inside IOURequestStepDistanceOdometer. That keeps the odometer's keyboard handling working while the Map-hosting container's height is no longer coupled to it, so switching back to the map can't leave it shrunken. This needs an iOS screenshot/video to verify since it's not meaningfully Jest-testable.

What alternative solutions did you explore? (Optional)

Always enabling the shared KAV (shouldEnableKeyboardAvoidingView={true}) fixes the toggle but changes keyboard behavior for the Map, Manual, and GPS tabs too. Manual has no KAV by design, so this broadens behavior across tabs that were never in scope. I'd rather scope the KAV to the tab that actually needs it than change the shared wrapper for everyone.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 11:00:13 UTC.

Proposal

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

In the Track distance flow, after editing an odometer reading and confirming "Discard changes" when tapping the Map tab, the Map tab renders vertically cropped — the bottom of the screen (roughly one keyboard height) stays blank/squeezed until the flow is reopened.

What is the root cause of that problem?

All four distance tabs share one ScreenWrapper, and its KeyboardAvoidingView is enabled only while the Odometer tab is selected:

1. The gate: DistanceRequestStartPage.tsx#L114-L119 — shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER}. This wraps the whole tab navigator in one KAV (ScreenWrapperContainer.tsx#L232-L239, behavior padding), which on iOS/Android is react-native-keyboard-controller's KAV (BaseKeyboardAvoidingView/index.ios.tsx).
2. Editing a reading opens the numeric keyboard, so the KAV applies paddingBottom ≈ keyboard height to the entire screen content.
3. Tapping the Map tab is intercepted by the tab-switch guard, which shows the discard modal (OnyxTabNavigator.tsx#L169-L206). Nothing blurs the odometer input, so the keyboard (and the padding) stays.
4. On confirm, the guard runs handleTabSwitchDiscard — which only clears the draft, never dismisses the keyboard (IOURequestStepDistanceOdometer.tsx#L513-L521) — then dispatches jumpTo. The tab-state listener writes the new tab to Onyx (OnyxTabNavigator.tsx#L265), the page re-renders, and the gate flips enabled to false while the keyboard is still on screen.
5. Here is the mechanism that makes the crop permanent. RNKC's KAV worklet early-returns when disabled — if (!enabled) return {} (upstream KeyboardAvoidingView/index.tsx#L168-L170 at 1.21.0; identical in the pinned 1.21.0-beta.1). Reanimated's styleUpdater only applies the keys the worklet returns — keys omitted from the new object are never reset (useAnimatedStyle.ts, reanimated 4.3.1: updateProps receives only newValues). So the last non-zero paddingBottom stays baked onto the native view. Worse, once disabled the worklet no longer reads keyboard.progress, so the later keyboard-hide animation can't update it either. Nothing ever writes paddingBottom: 0 again.

Structural cause: the shared KAV's enabled flag is derived from the selected tab alone, so it can turn off while the keyboard it was avoiding is still up — and disabling this KAV mid-keyboard leaks the applied padding permanently. This explains every detail: the crop equals the keyboard height, it appears exactly after "Discard changes" (the only step that flips the tab under an open keyboard), and it persists after the keyboard closes. The linked PR #95039 only changed the odometer typing-guard baseline; it surfaced this in QA but didn't create the mechanism.

Affected paths (all covered by the fix below):

• The reported discard path, to any destination tab — Map, Manual, or GPS all render cropped.
• The no-modal path: edit a reading and revert it to the saved value (after #95039 that counts as "no unsaved changes"), or just focus without typing, then tap another tab — switches instantly with the keyboard open, same freeze, no discard modal involved.
• Android: same shared component (index.android.tsx), so the hardware-back guard path is also exposed; the platform checkbox reflects where QA found it.

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

Keep the KAV enabled until the keyboard has fully closed, at the single gate every path converges on (DistanceRequestStartPage.tsx#L115):

const {isKeyboardShown} = useKeyboardState();
// ...
shouldEnableKeyboardAvoidingView={selectedTab === CONST.TAB_REQUEST.DISTANCE_ODOMETER || isKeyboardShown}

isKeyboardShown only flips false on keyboardDidHide — after the hide animation completes (withKeyboardState.tsx#L50-L53) — so the worklet keeps tracking keyboard.progress, animates the padding back to 0, and the KAV is only disabled once the padding is already 0, which makes the disable a no-op by construction. I'd also add Keyboard.dismiss() inside handleTabSwitchDiscard so the keyboard visibly retracts with the modal instead of lingering over the map for a beat.

Regression safety: the odometer tab is unchanged, and on the other tabs the KAV was previously inert, so the only delta is keyboard-avoidance while a keyboard is actually visible — the standard expectation.

Why the obvious spot-fix fails: calling Keyboard.dismiss() before jumpTo in the discard branch only starts the hide animation; jumpTo writes the selected tab to Onyx and the re-render flips enabled to false a frame later, while keyboard.progress is still mid-flight — the worklet returns {} and Reanimated never resets the already-applied padding, so a (slightly smaller) crop remains. Awaiting full dismissal before switching would fix only this path, delays every discard by the keyboard animation, and misses the no-modal edit-revert path entirely.

What alternative solutions did you explore? (Optional)

1. Strictly-scoped latch — keep the KAV enabled only while leaving the odometer tab with a keyboard open (usePrevious(selectedTab)), guaranteeing zero behavior change on Manual/GPS typing. Slightly more code; happy to use this variant if preferred.
2. Fix the leak at the source — patch react-native-keyboard-controller's KAV (patch-package + upstream PR) to return explicit resets ({paddingBottom: 0}) when disabled. Protects every ScreenWrapper that toggles shouldEnableKeyboardAvoidingView dynamically (e.g. ReportScreen, CreateDistanceRatePage), but edits a vendored dependency for what today reproduces in one flow.
3. Dismiss-then-navigate in OnyxTabNavigator — the spot fix competitors will propose; incomplete for the reasons above.

[samranahm]

Proposal

What is the root cause of that problem?

After editing the odometer, switching to the Map tab, and tapping "Discard changes", the distance map renders cropped instead of fitting the window.

The Track distance flow renders its tabs (Distance / Manual / Odometer) inside an OnyxTabNavigator, and the Map tab shows the route through the DistanceMapView component, which wraps MapView and draws the route via ConfirmedRoute.tsx. The map camera is positioned by fitting the route/waypoint bounds to the map container size once, when the map mounts or when the waypoints change.

The problem is a measurement race: while the Odometer tab is the active tab, the Map tab is off-screen (or has zero/partial dimensions). When the user taps the Map tab and then "Discard changes", the map view becomes visible and mounts, but the fitBounds/camera bounds are computed against stale or zero container dimensions from the hidden tab. The camera is never recomputed once the container settles to its final on-screen size, so the map stays zoomed/panned incorrectly and appears cropped. The map component does not re-fit its bounds on the container onLayout/resize event after the tab becomes visible, which is why the crop only appears in this edit-then-discard-then-Map sequence and not on a fresh open.

Because the investigation snippets provided do not surface the distance map components, the exact fitBounds call and onLayout handler live in ConfirmedRoute.tsx, DistanceMapView, and MapView under src/components, and that is where the missing re-fit occurs.

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

1. In ConfirmedRoute.tsx, the route currently fits camera bounds based on waypoints/route in an effect that runs on data change. Add the map container size (captured from the MapView onLayout width/height) as a dependency so bounds are recomputed whenever the container resizes from zero/partial to its final on-screen size.

2. In MapView (the mapbox wrapper under src/components/MapView), expose the measured layout size (or a didFinishLoadingMap/onMapLoaded re-fit callback) so consumers can re-run fitBounds after the map becomes visible. Trigger a re-fit when the measured width/height transitions from 0 to a real value.

3. In DistanceMapView, ensure the map is only asked to fit bounds after it is actually visible on the active tab, so the initial fit uses correct dimensions. Gate the fit on a non-zero measured size rather than on mount alone.

This fixes the root cause because the camera bounds will be recalculated once the Map tab is shown at its real size, instead of relying on the stale dimensions captured while the tab was hidden behind the Odometer view.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.