[Due for payment 2026-03-11][$250] Date picker does not auto-open when selecting “Date” from editable expense

[m-natarajan]

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.3.20-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @twisterdotcom
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create an expense
2. Save the expense
3. Open the expense for editing
4. Tap/click on Date

Expected Result:

The date picker should open immediately upon tapping/clicking “Date”
No additional tap should be required
This behavior should be consistent anywhere in the app where a single Date field pushes to its own page — the picker should auto-open upon navigation.

Actual Result:

User is navigated to the Date page
The date picker does not open automatically
User must tap the date field again to open it

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

ScreenRecording_02-16-2026.08-15-24_1.MP4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (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.

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[twilight2294]

Proposal

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

When a user taps "Date" from an editable expense on iOS (or any small screen device), they are navigated to a dedicated Date editing page, but the date picker calendar does not automatically open — requiring an extra tap to open it. This is an unnecessary friction point given the user's clear intent to change the date.

What is the root cause of that problem?

The root cause is in src/components/DatePicker/index.tsx at lines 112–121. The useEffect responsible for auto-opening the date picker modal contains an early return guard that includes isSmallScreenWidth:

useEffect(() => {
    if (!autoFocus || isAutoFocused.current || isSmallScreenWidth) {  // Bug on this line
        return;
    }
    isAutoFocused.current = true;
    InteractionManager.runAfterInteractions(() => {
        handlePress();
    });
}, [handlePress, autoFocus, isSmallScreenWidth]);

On mobile devices, isSmallScreenWidth is always true, which means the early return is always triggered and handlePress() (which calls setIsModalVisible(true)) is never executed — even when autoFocus={true} is explicitly passed.

The isSmallScreenWidth check was originally added to prevent auto-focus behavior on small devices, but this also inadvertently prevents the intended auto-open behavior when navigating to the dedicated src/pages/iou/request/step/IOURequestStepDate.tsx page, which passes autoFocus={true} at line 153 specifically to trigger this auto-open behavior.

The autoFocus prop from IOURequestStepDate.tsx is the only consumer of this auto-open path in the DatePicker component, so the isSmallScreenWidth guard directly blocks the entire intended use case on mobile.

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

Remove the isSmallScreenWidth guard from the autoFocus effect in src/components/DatePicker/index.tsx:

// Remove isSmallScreenWidth from the condition:
useEffect(() => {
    if (!autoFocus || isAutoFocused.current) {
        return;
    }
    isAutoFocused.current = true;
    InteractionManager.runAfterInteractions(() => {
        handlePress();
    });
}, [handlePress, autoFocus]);

Since isSmallScreenWidth is only used in this one effect within the component, the useResponsiveLayout() destructure and its associated comment (lines 40–42) can also be removed entirely. The InteractionManager.runAfterInteractions wrapper already ensures the modal opens after layout is complete, making the guard unnecessary.

What alternative solutions did you explore? (Optional)

An alternative approach would be to fix this in src/pages/iou/request/step/IOURequestStepDate.tsx by rendering an inline CalendarPicker directly on mobile instead of relying on the popover-based DatePicker auto-open. However, this would be more invasive and would require duplicating rendering logic, whereas removing the isSmallScreenWidth guard is a minimal, targeted fix with low risk since the autoFocus prop is only passed from IOURequestStepDate.

[Eskalifer1]

I think this is expected due to #79892

[twisterdotcom]

Yes, as discussed in Slack, we are going to change this behaviour for all single page date fields.

[MelvinBot]

Proposal

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

When a user edits an expense and taps "Date" on iOS, they are navigated to the Date page but the date picker calendar does not auto-open. The user must tap the date field again to open it. This should be consistent for any single Date field that navigates to its own page — the picker should auto-open upon navigation.

What is the root cause of that problem?

The autoFocus useEffect in src/components/DatePicker/index.tsx (lines 112-121) contains an isSmallScreenWidth guard that prevents auto-opening the date picker modal on small screens:

useEffect(() => {
    if (!autoFocus || isAutoFocused.current || isSmallScreenWidth) {
        return;
    }
    // ...
    handlePress();
}, [handlePress, autoFocus, isSmallScreenWidth]);

On native (iOS/Android), isSmallScreenWidth is always true because useResponsiveLayout/index.native.ts hardcodes it at line 29:

const isSmallScreenWidth = true;

This means the autoFocus effect unconditionally returns early on native, and handlePress() (which opens the calendar modal via setIsModalVisible(true)) is never called — even though IOURequestStepDate.tsx explicitly passes autoFocus at line 153.

This guard was intentionally added in PR #79892 to fix a WCAG 3.2.1 accessibility concern (issue #79242) where the date picker auto-opened on page load. However, per the Slack discussion referenced in this issue, the decision has been made to change this behavior for all single-page date fields.

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

Remove the isSmallScreenWidth guard from the autoFocus useEffect in src/components/DatePicker/index.tsx:

1. Remove isSmallScreenWidth from the early-return condition at line 113
2. Remove isSmallScreenWidth from the useEffect dependency array
3. Since isSmallScreenWidth is only used in this one effect, the useResponsiveLayout() import and destructure (lines 9, 40-42) can also be removed

The InteractionManager.runAfterInteractions wrapper already ensures the modal opens after layout is complete, so the guard is not needed for rendering safety.

Note: This affects 8 call sites that pass autoFocus to DatePicker (IOURequestStepDate, DateOfBirthStep, DateOfBirthPage, SetDatePage, EditReportFieldDate, SearchEditMultipleDatePage, SplitExpenseCreateDateRagePage, IncorporationDateBusiness). All of these navigate to a dedicated date-editing page, so auto-opening the picker is the desired behavior.

What alternative solutions did you explore? (Optional)

An alternative would be to add a new prop (e.g., forceAutoFocus) that bypasses the isSmallScreenWidth check, allowing call sites to opt in. However, since all 8 consumers already pass autoFocus with the intent to auto-open, and the Slack discussion confirms this should be the behavior everywhere, a separate prop adds unnecessary complexity. Removing the guard is the minimal, targeted fix.

---

Existing proposal note: @twilight2294's proposal identifies the same root cause and proposes the same fix. This analysis confirms their findings with additional evidence (all 8 affected call sites, the WCAG context from PR #79892/issue #79242, and the native-specific useResponsiveLayout hardcoding).

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.