focus input on perDiem tab on tab change by Eskalifer1 · Pull Request #71013 · Expensify/App

Eskalifer1 · 2025-09-22T17:53:23Z

Explanation of Change

This PR fixes a bug on iOS native where when switching between tabs while creating an expense in the input, the focus immediately disappears from the perDiem tab.

Fixed Issues

$#67907
PROPOSAL:#67907 (comment)

Tests

Preconditions: Have a workspace with Per Diem enabled.

Tap the FAB (Floating Action Button)
Navigate to the Per Diem tab
Make sure input is autofocused and keyboard appears
Navigate to any other tab(e.g. Scan)
Navigate to Per Diem tab
Make sure input is autofocused and keyboard appears

Verify that no errors appear in the JS console

Offline tests

Same as tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
Same as tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

67907-android-native.mov

Android: mWeb Chrome

67907-android-web.mov

iOS: Native

67907-ios-natibe.mov

iOS: mWeb Safari

67907-ios-web.mov

MacOS: Chrome / Safari

67907-web.mov

melvin-bot · 2025-09-22T17:53:29Z

@jayeshmangwani Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

jayeshmangwani · 2025-09-26T06:54:36Z

    };

+type IOURequestStepDestinationRef = {


Please move this above the IOURequestStepDestinationProps, before its usage.

jayeshmangwani · 2025-09-26T07:00:13Z

@Eskalifer1 , we previously faced a blocker #70904 because there was a delay in focusing on the amount input. After our PR, there’s now a delay in focusing on the per diem search input.

I’m adding a video below to compare the delay between the current version and our PR version. Either we need to fix this delay, or we should explicitly mention in the QA section that the delay is expected, otherwise, we risk running into another deploy blocker.

Current prod/staging behaviour

staging-per-diem.mov

PR behaviour

dev-per-diem.mov

Eskalifer1 · 2025-09-27T10:35:42Z

@jayeshmangwani I think this is expected behavior, since all tabs that use this approach have this delay. For example, here is the page for creating a new chat:

2025-09-27.13.32.25.mov

codecov · 2025-09-27T10:45:47Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/components/DestinationPicker.tsx	`0.00% <0.00%> (ø)`
...ges/iou/request/step/IOURequestStepDestination.tsx	`2.81% <0.00%> (-0.13%)`	⬇️
src/pages/iou/request/IOURequestStartPage.tsx	`71.09% <42.85%> (-2.55%)`	⬇️
... and 289 files with indirect coverage changes

jayeshmangwani · 2025-09-29T05:58:14Z

@Eskalifer1 Please fix the autofocus on this page. When we have multiple per diem workspaces and need to select from the list, the autofocus doesn’t work.

no-auto-focus.mov

Eskalifer1 · 2025-09-29T08:30:04Z

@jayeshmangwani Yes, thank you for noticing this bug. I suggest changing the approach, because when switching from the Workspace selection screen to the perDiem page itself, the onTabChange function is not called (since we remain on the same tab).

Also, we use this component in another place, so if we leave the focus only when changing tabs, there will be no focus in another place.

I suggest using the following approach:
Remove all the logic that is currently in ref on the IOURequestStartPage page and use the following hook on the IOURequestStepDestination page:

    useFocusEffect(
        useCallback(() => {
            setTimeout(() => {
                InteractionManager.runAfterInteractions(() => {
                    destinationSelectionListRef.current?.focusTextInput?.();
                });
            }, 1000);
        }, []),
    );

The advantage of this approach is that regardless of where this component is used, we will focus the input. We can also move this to a separate hook that will add a delay only on iOS, while on all other environments the focus will occur instantly (since the bug we are trying to fix only affects iOS).

PS: A 1-second delay is needed to focus the input immediately after changing the tab, because if we try to do it earlier, we will either lose focus or the application will crash.

Please write what you think about this, and if this approach suits us, let me know what would be the best name for the hook, as well as which approach you think is better to use (pass a function to it or have it return a ref).

jayeshmangwani · 2025-09-29T14:43:08Z

@Eskalifer1 The setTimeout approach doesn’t look good to me, but I noticed we’re using it in some places with the ANIMATED_TRANSITION delay. Could you please check how we’re handling this in other spots where we refocus the same page?

Eskalifer1 · 2025-09-29T14:47:34Z

I don't think the ANIMATED_TRANSITION approach will help us, because it is a constant that controls the duration of the swipe between opening a page via RHP and has a duration of 300ms. In our case, this is too short, because we will lose focus with this approach.

Also, I couldn't find a single place where we would use this approach for tabs, since the onTabSelect approach is used everywhere, but in this case it won't work for us.

cc: @jayeshmangwani

jayeshmangwani · 2025-09-30T08:20:29Z

@Eskalifer1 , I think setTimeout isn’t a good option here if we can avoid it. Can we use the didScreenTransitionEndapproach, similar to how we do in NewChatPage?

Eskalifer1 · 2025-09-30T08:37:35Z

Hi @jayeshmangwani, Could you please describe in more detail what approach you mean?

If it's this part of the code, then setTimeout is also used here, but its value is not suitable for us because it is too small:

App/src/pages/NewChatPage.tsx

Lines 108 to 116 in bda97bb

    
           useFocusEffect( 
        
               useCallback(() => { 
        
                   focusTimeoutRef.current = setTimeout(() => { 
        
                       setDidScreenTransitionEnd(true); 
        
                   }, CONST.ANIMATED_TRANSITION); 
        
                   return () => focusTimeoutRef.current && clearTimeout(focusTimeoutRef.current); 
        
               }, []), 
        
           );

jayeshmangwani · 2025-09-30T08:43:30Z

I meant to use the same approach as other pages where the ANIMATED_TRANSITION duration is used. Using 1000ms feels like too much of a delay. Are there any other pages where we use 1000ms or more for focusing input?

Eskalifer1 · 2025-09-30T09:00:05Z

As far as I know, there is currently no such approach in the project, since Tab usually uses the onTabSelect approach, for example on the NewChatPage page:

App/src/pages/NewChatSelectorPage.tsx

Lines 41 to 54 in bda97bb

    
           // We're focusing the input using internal onPageSelected to fix input focus inconsistencies on native. 
        
           // More info: https://github.com/Expensify/App/issues/59388 
        
           const onTabSelectFocusHandler = ({index}: {index: number}) => { 
        
               // We runAfterInteractions since the function is called in the animate block on web-based 
        
               // implementation, this fixes an animation glitch and matches the native internal delay 
        
               InteractionManager.runAfterInteractions(() => { 
        
                   // Chat tab (0) / Room tab (1) according to OnyxTabNavigator (see below) 
        
                   if (index === 0) { 
        
                       chatPageInputRef.current?.focus(); 
        
                   } else if (index === 1) { 
        
                       roomPageInputRef.current?.focus(); 
        
                   } 
        
               }); 
        
           };

However, in this case, this approach is not suitable for us, and a delay of 300 ms will not be enough, since a complete transition between tabs takes more than 300 ms.

jayeshmangwani · 2025-09-30T09:09:07Z

I’m on another PR right now, but once I wrap it up, I’ll get back to this PR to move it forward in a few hours.

jayeshmangwani · 2025-10-06T05:13:36Z

Hey @Eskalifer1 , can you please update the code and add this change #71013 (comment)? I want to test it, and we can go with this for now. Please use any relevant name for the hook , we can finalize it later.

Eskalifer1 · 2025-10-06T13:14:04Z

Hi @jayeshmangwani PR updated!

If this option is not suitable for some reason, we can pass here:

App/src/components/DestinationPicker.tsx

Lines 74 to 85 in 7585b7f

    
           <SelectionList 
        
               sections={sections} 
        
               headerMessage={headerMessage} 
        
               textInputValue={searchValue} 
        
               textInputLabel={shouldShowTextInput ? translate('common.search') : undefined} 
        
               onChangeText={setSearchValue} 
        
               onSelectRow={onSubmit} 
        
               ListItem={RadioListItem} 
        
               initiallyFocusedOptionKey={selectedOptionKey ?? undefined} 
        
               isRowMultilineSupported 
        
               shouldHideKeyboardOnScroll={false} 
        
           />

textInputAutoFocus as false only if it is iosNative and, accordingly, call the hook useTabFocusInput also only if it is iosNative.

jayeshmangwani · 2025-10-06T14:38:08Z

Thanks for updating the PR!

jayeshmangwani · 2025-10-13T06:10:05Z

Hey @Eskalifer1 , I’m testing your latest changes on the web, and I’ve noticed that sometimes the focus doesn’t seem to happen at all. It’s not consistent, it happens occasionally. Check out the video below where I compared the staging and dev environments. Could you try to reproduce this on your end and see if you face the same issue for an account where a few workspaces have per diem enabled? Please also try testing after a fresh login.

web-bug.mov

Eskalifer1 · 2025-10-13T10:03:28Z

Hi @jayeshmangwani, I believe I understand the issue. This bug is most likely related to InteractionManager. There is a bug on the web where, when swiping tabs, InteractionManager sometimes does not work. We even have an open task with this RCA.

So I think we can just replace InteractionManager with requestIdleCallback. I think this completely fixes the problem, and besides, InteractionManager is already considered deprecated.

What do you think about this? Please check it out and let me know. Thank you!

jayeshmangwani · 2025-10-14T19:03:01Z

I’m still trying to test things with requestIdleCallback, but I just can’t figure out why InteractionManager isn’t working for the Per Diem tab specifically.

jayeshmangwani · 2025-10-21T15:23:02Z

@Eskalifer1 @madmax330 , I think we should close this PR and look for new proposals for the issue #67907, since the suggested solution didn’t work during testing #71013 (comment). WDYT?

Eskalifer1 · 2025-10-21T15:46:43Z

Hi @jayeshmangwani i proposed solution here to use requestIdleCallback instead of InteractionManager , since this fix this issue and anyway InteractionManager is deprecated in the project now.

But if you think this approach is not good enough, then we can close this PR and you can try to find a better solution.

jayeshmangwani · 2025-10-21T16:04:26Z

@Eskalifer1 I haven’t seen any usage of requestIdleCallback in the app. I think you suggested it but didn’t apply it in the code, and there’s also no video evidence showing how it would look in the app.

Eskalifer1 · 2025-10-21T16:11:12Z

As far as I know (I worked on another PR), a polyfill for requestIdleCallback is currently being developed, so all PRs that plan to use requestIdleCallback are waiting for this moment.

In addition, as I mentioned above, InteractionManager is already deprecated and cannot be added to the project. Therefore, in any case, it cannot be used here.

As for the video, I can record how it looks if necessary.

cc: @jayeshmangwani

jayeshmangwani · 2025-10-22T06:15:22Z

please mention the PR here so I can see too

jayeshmangwani · 2025-10-29T11:56:00Z

@Eskalifer1 , could you please mention the PR where the requestIdleCallback changes are being worked on? Alternatively, you could make those changes in this PR so I can test and confirm whether that approach works or if any unexpected behavior occurs.

Eskalifer1 · 2025-10-30T10:36:48Z

Hi @jayeshmangwani, i merged main, can you please retest if you can still reproduce the bug you wrote about earlier? Because I tried and I can't reproduce it now.

jayeshmangwani · 2025-10-30T12:04:47Z

@Eskalifer1 I’m not able to reproduce it on the latest merged main either. But since we’ve deprecated the InteractionManager, we’ll need to change the approach and avoid using it here.

Also, could you please share the PR where you worked on requestIdleCallback?

Eskalifer1 · 2025-10-30T12:23:06Z

@jayeshmangwani I was working on a task where we initially wanted to use InteractionManager, but that was just when it became deprecated, and C+ said we could use requestIdleCallback but put the task on HOLD until the polyfill was ready. Later, we changed our approach there, but as far as I understand, we now use requestIdleCallback instead of InteractionManager.

I can ask on Slack what to do in such situations if necessary.

jayeshmangwani · 2025-11-02T05:58:36Z

Thanks for the update, please tag me on Slack or share the discussion link here so I can follow along.

Eskalifer1 · 2025-11-20T17:47:18Z

Hi everyone, seems like we can HOLD this issue for now. Solutions are currently being sought for cases such as this, in the context of the project to remove InteractionManager.

Eskalifer1 · 2026-01-02T01:00:18Z

Hi @jayeshmangwani, Can you review this PR again please? I updated it because it seems that the issue has been fixed and now we can use requestAnimationFrame instead of InteractionManager.

Eskalifer1 · 2026-01-12T19:02:51Z

Hi @jayeshmangwani! Bump on review here, conflicts is fixed!

jayeshmangwani · 2026-01-14T05:00:10Z

Sorry, missed the ping here, I’ll re-test the PR later today.

jayeshmangwani · 2026-01-16T07:03:54Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified there are no new alerts related to the canBeMissing param for useOnyx
I verified proper code patterns were followed (see Reviewing the code)
- I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
- I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
- I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
- I verified the JSDocs style guidelines (in STYLE.md) were followed
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately and each prop has a /** comment above it */
- The file is named correctly
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android-1.mov

Android-2.mov

Android: mWeb Chrome

mweb-chrome-2.mov

mweb-chrome.mov

iOS: HybridApp

ios-1.mov

ios-2.mov

iOS: mWeb Safari

mweb-safari-2.mov

mweb-safari.mov

MacOS: Chrome / Safari

web-1.mov

web-2.mov

…itional rendering

jayeshmangwani

LGTM 🚀

OSBotify · 2026-01-19T15:57:53Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

OSBotify · 2026-01-20T17:40:50Z

🚀 Deployed to staging by https://github.com/madmax330 in version: 9.3.5-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

OSBotify · 2026-01-21T23:05:19Z

🚀 Deployed to production by https://github.com/Beamanator in version: 9.3.5-7 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Eskalifer1 requested a review from a team as a code owner September 22, 2025 17:53

melvin-bot Bot requested a review from jayeshmangwani September 22, 2025 17:53

melvin-bot Bot assigned Eskalifer1 Sep 22, 2025

melvin-bot Bot removed the request for review from a team September 22, 2025 17:53

Eskalifer1 mentioned this pull request Sep 22, 2025

[Due for payment 2026-01-28] [$250] iOS – Per Diem page input loses focus immediately; do not autofocus field #67907

Closed

16 tasks

jayeshmangwani reviewed Sep 26, 2025

View reviewed changes

Eskalifer1 force-pushed the fix/67907 branch from a96471f to f85d22b Compare October 6, 2025 11:45

Eskalifer1 mentioned this pull request Nov 14, 2025

[Due for payment 2026-06-24] [Partial Payment][Tracking] Deprecation of InteractionManager #71913

Open

Eskalifer1 added 2 commits January 2, 2026 02:38

fix:67907: autoFocus input on perDiem tab

373ece5

fix eslint

0318c88

Eskalifer1 force-pushed the fix/67907 branch from 4a11095 to 0318c88 Compare January 2, 2026 00:45

Eskalifer1 requested a review from a team as a code owner January 2, 2026 00:45

Eskalifer1 mentioned this pull request Jan 5, 2026

[$250] Create expense - Search field not autofocussed on Perdiem tab when switching from Manual or Scan tab #78868

Closed

7 tasks

merge main

4e2d812

Eskalifer1 added 2 commits January 16, 2026 11:17

fix:67907: Fix focus handling for per diem input and comment out cond…

2b8c329

…itional rendering

fix: show dynamic perDiem tab

991b5b4

jayeshmangwani approved these changes Jan 17, 2026

View reviewed changes

melvin-bot Bot requested a review from madmax330 January 17, 2026 16:11

madmax330 approved these changes Jan 19, 2026

View reviewed changes

madmax330 merged commit f6e1833 into Expensify:main Jan 19, 2026
30 checks passed

OSBotify mentioned this pull request Jan 20, 2026

Deploy Checklist: New Expensify 2026-01-20 #80009

Closed

85 tasks

suneox mentioned this pull request Mar 30, 2026

[Due for payment 2026-03-31] [$250] iOS – Per Diem page does not autofocus the input field #85277

Closed

7 tasks

		};

		type IOURequestStepDestinationRef = {

Conversation

Eskalifer1 commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Sep 22, 2025

Uh oh!

jayeshmangwani Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

jayeshmangwani commented Sep 26, 2025

Uh oh!

Eskalifer1 commented Sep 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Sep 27, 2025 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jayeshmangwani commented Sep 29, 2025

Uh oh!

Eskalifer1 commented Sep 29, 2025

Uh oh!

jayeshmangwani commented Sep 29, 2025

Uh oh!

Eskalifer1 commented Sep 29, 2025

Uh oh!

jayeshmangwani commented Sep 30, 2025

Uh oh!

Eskalifer1 commented Sep 30, 2025

Uh oh!

jayeshmangwani commented Sep 30, 2025

Uh oh!

Eskalifer1 commented Sep 30, 2025

Uh oh!

jayeshmangwani commented Sep 30, 2025

Uh oh!

jayeshmangwani commented Oct 6, 2025

Uh oh!

Eskalifer1 commented Oct 6, 2025

Uh oh!

jayeshmangwani commented Oct 6, 2025

Uh oh!

jayeshmangwani commented Oct 13, 2025

Uh oh!

Eskalifer1 commented Oct 13, 2025

Uh oh!

jayeshmangwani commented Oct 14, 2025

Uh oh!

jayeshmangwani commented Oct 21, 2025

Uh oh!

Eskalifer1 commented Oct 21, 2025

Uh oh!

jayeshmangwani commented Oct 21, 2025

Uh oh!

Eskalifer1 commented Oct 21, 2025

Uh oh!

jayeshmangwani commented Oct 22, 2025

Uh oh!

jayeshmangwani commented Oct 29, 2025

Uh oh!

Eskalifer1 commented Oct 30, 2025

Uh oh!

jayeshmangwani commented Oct 30, 2025

Uh oh!

Eskalifer1 commented Oct 30, 2025

Uh oh!

jayeshmangwani commented Nov 2, 2025

Uh oh!

Eskalifer1 commented Nov 20, 2025

Uh oh!

Eskalifer1 commented Jan 2, 2026

Uh oh!

Eskalifer1 commented Jan 12, 2026

Eskalifer1 commented Sep 22, 2025 •

edited

Loading

Eskalifer1 commented Sep 27, 2025 •

edited

Loading

codecov Bot commented Sep 27, 2025 •

edited by github-actions Bot

Loading