[Due for payment 2026-03-16] [$250] iOS - Expense - Unable to see the fourth split row while put cursor on it

[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.1-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/test-runs/TR-2945/folder/13176791/59413485/1123997648
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 16 pro/ 26.2
App Component: Money Requests

Action Performed:

Precondition: Create a manual expense to workspace chat

1. Open app
2. Navigate to workspace chat having a manual expense
3. Tap on expense preview for go to detail page
4. Tap More button and select Split
5. Tap two times on Add split
6. Put cursor on the last row
7. Slide up screen for see the last row
8. Put cursor on the last row

Expected Result:

User can see the last row while put cursor on it

Actual Result:

After put cursor on the last row, keyboard appears and the last row is hidden. Slide up screen, keyboard is dismissed, user see the last row but tap on it, last row is hidden again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022011414870915223369
• Upwork Job ID: 2011414870915223369
• Last Price Increase: 2026-01-28
• Automatic offers:
• daledah | Contributor | 110270833

Issue Owner

Current Issue Owner: @laurenreidexpensify

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[annaweber830]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-20 11:40:22 UTC.

Proposal

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

User can see the last row while put cursor on it

What is the root cause of that problem?

The Split Expense list relies on SelectionList.scrollToFocusedInput() to reposition the list when an amount input gains focus. That helper currently:

• Scrolls the focused item to the very bottom of the list viewport (viewPosition: 1), which can still land behind the keyboard and/or the fixed footer, especially on iOS.
• Doesn’t reliably cancel prior scheduled scrolls because the timeout id isn’t stored, which can lead to inconsistent or stale scrolling behavior during rapid focus/scroll interactions.

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

• Update SelectionList.scrollToFocusedInput() to:
  • Persist and clear the scheduled timeout properly.
  • Scroll the focused row to a safer vertical position (e.g., mid-screen) rather than the very bottom, so it remains visible above the keyboard/footers when the keyboard appears.
• Keep the fix scoped to the existing “scroll on focus” behavior used by Split Expense, avoiding changes to business logic.
  We should replace this part.
  

  App/src/components/SelectionList/BaseSelectionList.tsx

  Lines 397 to 412 in e54cfd4

  	const scrollToFocusedInput = useCallback((item: TItem) => {
  	if (!listRef.current) {
  	return;
  	}
  	// Clear any existing timer before starting a new one
  	if (scrollTimeoutRef.current) {
  	clearTimeout(scrollTimeoutRef.current);
  	}
  	// Delay scrolling by 300ms to allow the keyboard to open.
  	// This ensures FlashList calculates the correct window size.
  	setTimeout(() => {
  	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
  	}, CONST.ANIMATED_TRANSITION);
  	}, []);

const scrollToFocusedInput = useCallback((item: TItem) => {
        if (!listRef.current) {
            return;
        }

        const keyForList = item.keyForList;

        // Clear any existing timer before starting a new one
        if (scrollTimeoutRef.current) {
            clearTimeout(scrollTimeoutRef.current);
        }

        
        scrollTimeoutRef.current = setTimeout(() => {
            const index = data.findIndex((option) => option.keyForList === keyForList);
            if (index < 0) {
                return;
            }

            try {
                listRef.current?.scrollToIndex({index, animated: true, viewPosition: 0, viewOffset: 24});
            } catch {
            }
        }, CONST.ANIMATED_TRANSITION);
    }, [data]);

App/src/components/SelectionList/ListItem/SplitListItem/SplitAmountInput.tsx

Line 55 in e54cfd4

onFocus={focusHandler}

onPress={focusHandler}
onFocus={focusHandler}

App/src/components/SelectionList/ListItem/SplitListItem/SplitPercentageInput.tsx

Line 43 in e54cfd4

onFocus={focusHandler}

onPress={focusHandler}
onFocus={focusHandler}

What alternative solutions did you explore? (Optional)

Screen.Recording.2026-01-20.at.3.41.45.AM.mov

[daledah]

Proposal

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

When user adds multiple splits on the Split Expense page and focuses on the last row's input field, the keyboard appears and hides the last row. Swiping up to see the row dismisses the keyboard, and tapping on the last row again repeats the cycle - the keyboard appears and hides the row again.

What is the root cause of that problem?

The root cause is a bug in the scrollToFocusedInput function in BaseSelectionList.tsx. The function creates a timeout to scroll after 300ms, but there's an issue:

1. The timeout reference is never actually stored in scrollTimeoutRef.current - only the clearing logic exists
2. This means if the user rapidly focuses/unfocuses, the scroll may not be properly debounced

Additionally, the scrollToItem call uses viewPosition: 1 which positions the item at the bottom of the visible area. However, when combined with keyboardAvoidingViewBehavior="height" in SplitExpensePage, there's a race condition where:

• The keyboard animation takes time to complete
• The FlashList's visible area calculation may not reflect the final keyboard-adjusted height
• The 300ms delay (CONST.ANIMATED_TRANSITION) may not be sufficient for iOS keyboard animation to fully complete

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

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

1. Fix the scrollToFocusedInput function to properly store the timeout reference
2. Use Keyboard.addListener to wait for the keyboard to fully appear before scrolling

// In src/components/SelectionList/BaseSelectionList.tsx
    const keyboardListenerRef = useRef<ReturnType<typeof Keyboard.addListener> | null>(null);
     ...
    const scrollToFocusedInput = useCallback(
        (item: TItem) => {
            if (!listRef.current) {
                return;
            }

            // Clear any existing timer and listener before starting new ones
            if (scrollTimeoutRef.current) {
                clearTimeout(scrollTimeoutRef.current);
            }
            if (keyboardListenerRef.current) {
                keyboardListenerRef.current.remove();
            }

            const performScroll = () => {
                const index = data.findIndex((dataItem) => dataItem.keyForList === item.keyForList);
                if (index === -1) {
                    return;
                }
                // Use scrollToIndex with viewPosition 0.5 to center the item in the visible area
                // This ensures the item is visible above the keyboard
                listRef.current?.scrollToIndex({index, animated: true, viewPosition: 0.5});
            };

            // Wait for keyboard to fully appear, then scroll
            keyboardListenerRef.current = Keyboard.addListener('keyboardDidShow', () => {
                keyboardListenerRef.current?.remove();
                keyboardListenerRef.current = null;
                // Clear fallback timeout since keyboard event fired
                if (scrollTimeoutRef.current) {
                    clearTimeout(scrollTimeoutRef.current);
                    scrollTimeoutRef.current = null;
                }
                // Add small delay after keyboard is shown for layout to settle
                scrollTimeoutRef.current = setTimeout(performScroll, 100);
            });

            // Fallback timeout in case keyboard event doesn't fire (e.g., keyboard already open)
            scrollTimeoutRef.current = setTimeout(() => {
                keyboardListenerRef.current?.remove();
                keyboardListenerRef.current = null;
                performScroll();
            }, CONST.ANIMATED_TRANSITION);
        },
        [data],
    );

This change ensures:

• The scroll happens only after the keyboard is fully visible
• Proper cleanup of event listeners and timeouts
• Fallback behavior when the keyboard is already open

What alternative solutions did you explore? (Optional)

result.mov

[MobileMage]

Proposal

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

On iOS, when splitting an expense with 4+ splits, users cannot keep the 4th row visible while editing it. When they focus the last row, the keyboard appears and hides the row. If they scroll up to see it, the keyboard immediately dismisses. Tapping the row again repeats the cycle.

What is the root cause of that problem?

The native SelectionList component unconditionally dismisses the keyboard when the user begins scrolling:

App/src/components/SelectionList/index.native.tsx

Lines 13 to 15 in 232cb11

	onScrollBeginDrag={() => {
	Keyboard.dismiss();
	}}

This creates an unusable cycle for editable lists where the user needs both the keyboard visible AND the ability to scroll to see hidden content.

The sibling component SelectionListWithSections already solved this problem by adding a shouldHideKeyboardOnScroll prop that defaults to true but can be set to false for editable scenarios:

App/src/components/SelectionListWithSections/index.native.tsx

Lines 6 to 17 in 232cb11

	function SelectionListWithSections<TItem extends ListItem>({shouldHideKeyboardOnScroll = true, ref, ...props}: SelectionListProps<TItem>) {
	return (
	<BaseSelectionList
	// eslint-disable-next-line react/jsx-props-no-spreading
	{...props}
	ref={ref}
	onScrollBeginDrag={() => {
	if (!shouldHideKeyboardOnScroll) {
	return;
	}
	Keyboard.dismiss();
	}}

However, SelectionList is missing this prop entirely.

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

Add the shouldHideKeyboardOnScroll prop to the native SelectionList component, matching the existing pattern in SelectionListWithSections:

In SelectionList/index.native.tsx, destructure shouldHideKeyboardOnScroll (default true) from props and conditionally call Keyboard.dismiss() only when it's true:

-function SelectionList<TItem extends ListItem>({ref, ...props}: SelectionListProps<TItem>) {
+function SelectionList<TItem extends ListItem>({ref, shouldHideKeyboardOnScroll = true, ...props}: SelectionListProps<TItem>) {
     return (
         <BaseSelectionList
             {...props}
             ref={ref}
             onScrollBeginDrag={() => {
+                if (!shouldHideKeyboardOnScroll) {
+                    return;
+                }
                 Keyboard.dismiss();
             }}
         />
     );
 }

Then in SplitList.tsx, pass shouldHideKeyboardOnScroll={false} to allow users to scroll while keeping the keyboard open:

     <SelectionList
         ...
         canSelectMultiple={false}
+        shouldHideKeyboardOnScroll={false}
     />

This keeps the default behavior unchanged for all existing usages while enabling the split expense list to work correctly.

What alternative solutions did you explore? (Optional)

Kapture.2026-01-14.at.11.28.56.mp4

[abbasifaizan70]

Proposal

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

On iOS, when splitting an expense and tapping on the last row's input field after adding multiple splits, the keyboard appears and hides the input row. The user cannot see the input field they're trying to edit.

What is the root cause of that problem?

The issue is in the scrollToFocusedInput function in BaseSelectionList.tsx. When a user taps on an input field in the last row, the function is triggered to scroll the item into view. However, there's a timing and positioning issue:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

The Problem Flow:

1. User taps on the last row input field
2. scrollToFocusedInput is called with a 300ms delay (CONST.ANIMATED_TRANSITION)
3. The keyboard starts animating open (iOS keyboard animation typically takes 250-300ms)
4. After 300ms, the scroll function executes with viewPosition: 1 (bottom of viewport) and viewOffset: 4
5. The scroll positions the item at what it calculates as the "bottom" of the visible area
6. However, the keyboard is still animating or just finishing its animation
7. As the keyboard finishes opening, it further reduces the visible viewport height
8. The input row ends up hidden behind the keyboard because the scroll calculation was based on a viewport that didn't account for the full keyboard height

Why viewOffset: 4 is insufficient:

The viewOffset: 4 only provides a 4-pixel offset from the bottom, which is far too small to account for:

• The iOS keyboard height (~291-346 pixels depending on device and orientation)
• Additional safe area padding
• The keyboard animation that may still be in progress

Why the workaround fails:

When users scroll up manually, the touch gesture dismisses the keyboard. Tapping on the input again triggers the same problematic scroll behavior, creating a frustrating loop.

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

Main Solution: Increase viewOffset to account for keyboard height

We need to increase the viewOffset parameter in the scrollToFocusedInput function to account for the typical iOS keyboard height. This ensures the input field is positioned well above where the keyboard will be.

File: App/src/components/SelectionList/BaseSelectionList.tsx

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

// After
const scrollToFocusedInput = useCallback((item: TItem) => {
    if (!listRef.current) {
        return;
    }

    // Clear any existing timer before starting a new one
    if (scrollTimeoutRef.current) {
        clearTimeout(scrollTimeoutRef.current);
    }

    // Delay scrolling by 300ms to allow the keyboard to open.
    // This ensures FlashList calculates the correct window size.
    // Use a larger viewOffset to account for typical iOS keyboard height (~320px)
    // This prevents the input from being hidden behind the keyboard
    setTimeout(() => {
        listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 320});
    }, CONST.ANIMATED_TRANSITION);
}, []);

What alternative solutions did you explore? (Optional)

Alternative 1: Change viewPosition instead of viewOffset

Instead of increasing viewOffset, we could change viewPosition from 1 (bottom) to 0.7 (70% from top):

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

const scrollToFocusedInput = useCallback((item: TItem) => {
    if (!listRef.current) {
        return;
    }

    if (scrollTimeoutRef.current) {
        clearTimeout(scrollTimeoutRef.current);
    }

    setTimeout(() => {
        // Position the item at 70% from the top instead of at the bottom
        listRef.current?.scrollToItem({item, viewPosition: 0.7, animated: true, viewOffset: 4});
    }, CONST.ANIMATED_TRANSITION);
}, []);

Alternative 2: Increase delay to wait for keyboard fully open

Increase the delay from 300ms to 500ms to ensure the keyboard is fully open before scrolling:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

const scrollToFocusedInput = useCallback((item: TItem) => {
    if (!listRef.current) {
        return;
    }

    if (scrollTimeoutRef.current) {
        clearTimeout(scrollTimeoutRef.current);
    }

    // Increase delay to 500ms to ensure keyboard is fully open
    // This allows FlashList to calculate the correct window size with keyboard visible
    setTimeout(() => {
        listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
    }, CONST.ANIMATED_TRANSITION + 200); // 500ms total
}, []);

Alternative 3: Get keyboard height dynamically (Most robust but complex)

Use keyboard event listeners to get the actual keyboard height and use it for viewOffset:

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 399 to 414 in 232cb11

	const scrollToFocusedInput = useCallback((item: TItem) => {
	if (!listRef.current) {
	return;
	}
	// Clear any existing timer before starting a new one
	if (scrollTimeoutRef.current) {
	clearTimeout(scrollTimeoutRef.current);
	}
	// Delay scrolling by 300ms to allow the keyboard to open.
	// This ensures FlashList calculates the correct window size.
	setTimeout(() => {
	listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: 4});
	}, CONST.ANIMATED_TRANSITION);
	}, []);

// Add at component level
const [keyboardHeight, setKeyboardHeight] = useState(0);

useEffect(() => {
    const keyboardWillShowListener = Keyboard.addListener(
        'keyboardWillShow',
        (e) => {
            setKeyboardHeight(e.endCoordinates.height);
        }
    );
    const keyboardWillHideListener = Keyboard.addListener(
        'keyboardWillHide',
        () => {
            setKeyboardHeight(0);
        }
    );

    return () => {
        keyboardWillShowListener.remove();
        keyboardWillHideListener.remove();
    };
}, []);

const scrollToFocusedInput = useCallback((item: TItem) => {
    if (!listRef.current) {
        return;
    }

    if (scrollTimeoutRef.current) {
        clearTimeout(scrollTimeoutRef.current);
    }

    setTimeout(() => {
        // Use actual keyboard height + small buffer
        const offset = keyboardHeight > 0 ? keyboardHeight + 20 : 320;
        listRef.current?.scrollToItem({item, viewPosition: 1, animated: true, viewOffset: offset});
    }, CONST.ANIMATED_TRANSITION);
}, [keyboardHeight]);

[paulnjs]

Proposal

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

After put cursor on the last row, keyboard appears and the last row is hidden. Slide up screen, keyboard is dismissed, user see the last row but tap on it, last row is hidden again.

What is the root cause of that problem?

The keyboard occlusion issue in the Amount tab was caused by a nested ScrollView in the NumberWithSymbolForm component. We're using MoneyRequestAmountInput → NumberWithSymbolForm → wraps everything in ScrollView.

The nested ScrollView inside the FlashList item was interfering with the parent list's scrollToFocusedInput behavior, preventing the list from scrolling properly when the keyboard appeared.

App/src/components/NumberWithSymbolForm.tsx

Lines 464 to 468 in 232cb11

	return (
	<ScrollView
	contentContainerStyle={styles.flexGrow1}
	style={!shouldWrapInputInContainer && styles.flexGrow0}
	>

The scroll behavior still working well in the Percentage tab since it uses PercentageForm which has no ScrollView wrapper.
With this, all the related issue in similar page like Date tab will be resolved and make the behavior consistently

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

Modified NumberWithSymbolForm to conditionally use ScrollView only when necessary:

App/src/components/NumberWithSymbolForm.tsx

Lines 464 to 470 in 232cb11

	return (
	<ScrollView
	contentContainerStyle={styles.flexGrow1}
	style={!shouldWrapInputInContainer && styles.flexGrow0}
	>
	{shouldWrapInputInContainer ? (
	<View style={[styles.flex1, styles.justifyContentCenter, styles.alignItemsCenter]}>

// Check if we need ScrollView (for BigNumberPad, footer, or container wrapping)
    const needsScrollView = shouldWrapInputInContainer || shouldShowBigNumberPad || !!footer;
    const hasAdditionalButtons = (isSymbolPressable || allowFlippingAmount) && canUseTouchScreen;

    const content = (
        <>
            {shouldWrapInputInContainer ? (
   .....

if (needsScrollView) {
        return (
            <ScrollView
                contentContainerStyle={styles.flexGrow1}
                style={!shouldWrapInputInContainer && styles.flexGrow0}
            >
                {content}
            </ScrollView>
        );
    }

    return content;

App/src/components/NumberWithSymbolForm.tsx

Line 501 in 232cb11

<View style={[styles.flexRow, styles.justifyContentCenter, shouldShowBigNumberPad ? styles.mb2 : styles.mb0, styles.gap2]}>

 {hasAdditionalButtons && (
                <View style={[styles.flexRow, styles.justifyContentCenter, shouldShowBigNumberPad ? styles.mb2 : styles.mb0, styles.gap2]}>
....

We can modify the condition to more strictly during PR implementation.

What alternative solutions did you explore? (Optional)

Screen.Recording.2026-01-14.at.18.09.09.mov

[melvin-bot]

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