Create expenses - ENTER on Merchant opens Schedule call after opening #admins and creating expense

[lanitochka17]

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.37-0
Reproducible in staging?: Yes
Reproducible in production?: No
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-8760/folder/13176730/41237111/1247678753
Email or phone of affected tester (no customers): sdiojiosdjnoijojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Log in with new Gmail account.
3. Create a workspace.
4. Go to #admins.
5. Go to workspace chat.
6. Click + > Create expense > Manual.
7. Enter amount.
8. Click Merchant.
9. Enter merchant and press Enter.

Expected Result:

RHP will return to confirm page.

Actual Result:

Schedule call page opens.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7101643_1773357467375.2.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @stitesExpensify (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: Unable to determine with high confidence
Related Issues: None identified

Recommendation: NEEDS INVESTIGATION

After thorough investigation of the staging deploy PRs and codebase, I cannot identify a single causing PR with high confidence. This appears to be a complex navigation state issue that requires deeper investigation.

Labels: No label changes made (keeping existing DeployBlockerCash label)

Detailed Analysis

Evidence

The bug shows specific characteristics:

• Occurs only on staging, not production (version 9.3.37-0)
• Happens specifically after navigating to #admins room first
• Pressing Enter on the Merchant field opens Schedule Call page instead of returning to confirm page
• Affects money request creation flow

Investigation Performed

I reviewed all PRs in the StagingDeployCash checklist and checked:

1. PRs affecting FormProvider and form submission (e.g., Update the input whenever the draft is updated #84844)
2. PRs affecting navigation state (fix: prevent navigation logic when screen isn't focused #81673, fix(duplicates): prevent offline forward navigation from getting stuck in loading #83827, Fix member import crash and missing navigation after confirmation #84799)
3. PRs affecting input handling and Enter key behavior
4. Recent changes to schedule call functionality

Technical Analysis

The merchant input field uses FormProvider which automatically adds an onSubmitEditing handler that calls submit() for single-line inputs. The issue suggests that:

• Either the form submission is navigating to the wrong route
• Or a navigation action/button press is being inadvertently triggered
• Or navigation state is corrupted after visiting #admins room

Why High Confidence Cannot Be Established

1. No PR in the staging deploy directly modifies the merchant input page (IOURequestStepMerchant.tsx)
2. No clear changes to form submission or Enter key handling that would cause this specific symptom
3. The 'after opening #admins' precondition suggests an edge case in navigation state management
4. Multiple PRs affect navigation, but none have obvious connections to this symptom

Next Steps Needed

1. Reproduce the issue locally to debug navigation state
2. Check browser console for navigation/routing errors
3. Add logging to track which navigation action is being triggered
4. Investigate if there is a focus/event handler leak from #admins header
5. Check if OnboardingHelpDropdownButton Schedule Call handler is being inadvertently invoked

[MelvinBot]

Proposal

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

When creating an expense from a workspace chat after previously visiting the #admins room, pressing Enter on the Merchant field navigates to the "Schedule call" page instead of returning to the expense confirmation page.

What is the root cause of that problem?

The OnboardingHelpDropdownButton rendered in the #admins room header (src/components/OnboardingHelpDropdownButton.tsx:132) passes pressOnEnter to a ButtonWithDropdownMenu. This registers a global Enter keyboard shortcut at priority 0 via the Button component's KeyboardShortcutComponent (src/components/Button/index.tsx:228).

When the user navigates from #admins to workspace chat, the split navigator keeps the last 2 central screens mounted (src/libs/Navigation/AppNavigator/createSplitNavigator/index.tsx:33), but freezes the #admins screen using react-freeze via ScreenFreezeWrapper (src/libs/Navigation/PlatformStackNavigation/createPlatformStackNavigatorComponent/ScreenFreezeWrapper.tsx). The split navigator has freezeNonTopScreens: true (line 44).

Because react-freeze suspends the React subtree, the useIsFocused() state change does not trigger a re-render of the frozen KeyboardShortcutComponent. This means the useKeyboardShortcut effect never runs to unsubscribe the Enter handler — the shortcut from the frozen #admins screen remains active.

When the user then opens the expense creation RHP and presses Enter on the Merchant field:

1. The frozen #admins button's handler fires at priority 0
2. The form's Save button handler (registered at priority 1 via FormWrapper at src/components/Form/FormWrapper.tsx:91) never fires because shouldBubble defaults to false
3. If the OnboardingHelpDropdownButton has a single option ("Schedule a call"), handleSingleOptionPress directly calls Navigation.navigate(ROUTES.SCHEDULE_CALL_BOOK) (src/components/OnboardingHelpDropdownButton.tsx:68)

Two additional factors allow the stale handler to fire on the Merchant input:

• The Merchant TextInput has role={CONST.ROLE.PRESENTATION} (IOURequestStepMerchant.tsx:173), which is explicitly exempted from the shouldDisableEnterShortcut check (Button/index.tsx:205)
• captureOnInputs defaults to true in useKeyboardShortcut, so the handler fires even on focused INPUT elements

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

Remove pressOnEnter from the OnboardingHelpDropdownButton's ButtonWithDropdownMenu in src/components/OnboardingHelpDropdownButton.tsx:132. This button is a help/onboarding dropdown — there is no compelling UX reason for it to register a global Enter keyboard shortcut. Removing it eliminates the conflict entirely.

What alternative solutions did you explore? (Optional)

1. Increase the form's Enter priority: Change enterKeyEventListenerPriority in FormWrapper from 1 to 0. This would make the form compete equally, but since handlers at the same priority are ordered by registration time, it wouldn't reliably fix the issue.

2. Fix the freeze-related stale subscription: Ensure keyboard shortcuts are explicitly unsubscribed when a screen is frozen by ScreenFreezeWrapper. This is a broader fix but is more invasive and could have unintended side effects on other frozen-screen behaviors.

3. Remove captureOnInputs for the OnboardingHelp button: Pass captureOnInputs: false so the shortcut doesn't fire when an INPUT element is focused. This is less clean than removing pressOnEnter entirely since the button doesn't need the Enter shortcut at all.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.