[$250] Money Request - Training tooltip doesn't appeared

[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.37-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: #84132
Email or phone of affected tester (no customers): sdfddffn@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Preconditions:

• Create a new account
• Create a workspace
• Enable Per Diem (add some rates) and Time expenses in more feature of the created workspace

Steps:

1. Click FAB button
2. using keyboard, press "Tab" and press "Enter" on the create expense
3. Observe the scan request

Expected Result:

The training Tooltip should appear and user can continue to the Tooltip

Actual Result:

The training Tooltip doesn't appeared

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ShridharGoel

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022032382632272104636
• Upwork Job ID: 2032382632272104636
• Last Price Increase: 2026-03-13

[MelvinBot]

Proposal

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

When a user opens the FAB menu and uses keyboard navigation (Tab + Enter) to select "Create expense," the training tooltip on the Scan tab does not appear. The tooltip is expected to show so the user can interact with it (e.g., "Try it out" / "No thanks").

What is the root cause of that problem?

There are two interacting issues, both related to keyboard navigation on web:

Primary cause — shouldHideOnScroll race condition (introduced by PR #84132):

PR #84132 changed the TabSelector container from a View to a ScrollView and added shouldHideOnScroll to the EducationalTooltip in TabSelectorItem.tsx:85. When the IOURequestStartPage mounts, the active tab (Scan) triggers scrollToTab during layout via TabSelectorContext.onTabLayout (which calls scrollIntoView). This emits a SCROLLING(true) event via DeviceEventEmitter. The event is followed by SCROLLING(false) after a 250ms debounce (useScrollEventEmitter.ts:28-31).

The tooltip display requires a multi-render async pipeline: Onyx updates selectedTab → shouldShow becomes true → useEffect registers the tooltip → context state updates → shouldShowProductTrainingTooltip propagates through props → EducationalTooltip mounts → onLayout fires → 500ms timer → tooltip shows. If the EducationalTooltip mounts during the 250ms scroll debounce window, the useLayoutEffect in BaseEducationalTooltip.tsx:103-114 subscribes to SCROLLING events and the scroll-end renderTooltip() call may fire before the tooltip's refs (tooltipElementRef, genericTooltipStateRef) are ready, causing a silent failure to show.

This is particularly triggered by the preconditions in this issue (Per Diem + Time enabled = 5 tabs), which causes the ScrollView to overflow and scroll during initial layout.

Secondary cause — keyboard double-fire of selectItem:

When a user presses Enter on a focused FAB menu item, the PopoverMenu's useKeyboardShortcut(ENTER) handler (PopoverMenu.tsx:458-468) fires in the capture phase (via react-native-key-command), calling selectItem(focusedIndex). Then React Native Web's PressResponder (PressResponder.js:236-256) processes the same keydown in the bubble phase, starts a press interaction, and on keyup fires onPress on the element — calling selectItem(menuIndex, event) a second time. Since useSingleExecution is a no-op on web (useSingleExecution/index.ts:10-20), both calls execute. This double-fires startMoneyRequest, which calls clearMoneyRequest + Navigation.navigate twice, potentially disrupting the tooltip mounting pipeline.

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

1. In TabSelectorItem.tsx: Remove shouldHideOnScroll from the EducationalTooltip (line 85), or replace it with a guarded version that ignores scroll events during the initial 500ms tooltip animation window. The training tooltip should persist regardless of tab bar scroll since it's an important educational element with action buttons.

2. In PopoverMenu.tsx (lines 458-468): Add a guard in the useKeyboardShortcut(ENTER) callback to prevent the PressResponder's subsequent onPress from double-firing selectItem. This could be done by tracking whether selectItem was already called for the current keypress (e.g., a ref flag reset on the next frame), or by calling event.stopImmediatePropagation() in the keyboard shortcut handler to prevent the event from reaching PressResponder.

What alternative solutions did you explore? (Optional)

• Delay scroll event subscription in BaseEducationalTooltip: Adding a delay before subscribing to SCROLLING events in the useLayoutEffect would avoid the race condition, but it's a general workaround rather than addressing the specific interaction.
• Pre-set selectedTab in Onyx for "Create expense": Similar to how "Quick Scan" at FloatingActionButtonAndPopover.tsx:370 explicitly calls Tab.setSelectedTab before startMoneyRequest, the "Create expense" action could pre-set the tab. This would reduce the async pipeline delay but doesn't fix the scroll or double-fire issues.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When the user has Per Diem or Time expenses enabled in their workspace, the training tooltip on the Scan tab of the "Create Expense" page does not appear, even when all other conditions for showing it are met.

What is the root cause of that problem?

The tooltip is conditionally registered inside IOURequestStartPage via useProductTrainingContext, and the shouldShow argument passed to that hook includes the condition selectedTab === CONST.TAB_REQUEST.SCAN. Here, selectedTab is derived directly from lastSelectedTab in Onyx — the most recently persisted tab selection. When a user has Per Diem or Time tabs available, the Onyx-persisted value can be PER_DIEM or TIME (from a prior visit), so this condition evaluates to false and the tooltip is never registered.

The effective initial tab the navigator actually renders is computed in OnyxTabNavigator as:

const validInitialTab = selectedTab && tabNames.includes(selectedTab) ? selectedTab : defaultSelectedTab;

The defaultSelectedTab in IOURequestStartPage is CONST.TAB_REQUEST.SCAN, so if there is no stored Onyx preference the navigator defaults to Scan. But IOURequestStartPage doesn't use this same validInitialTab logic — it checks the raw lastSelectedTab from Onyx, which may be a non-SCAN tab, causing the tooltip gate to fail even though the Scan tab is what's actually visible.

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

Lines 258 to 262 in 5ab0f25

	const {shouldShowProductTrainingTooltip, renderProductTrainingTooltip} = useProductTrainingContext(
	CONST.PRODUCT_TRAINING_TOOLTIP_NAMES.SCAN_TEST_TOOLTIP,
	// The test receipt image is served via our server on web so it requires internet connection
	!hasUserSubmittedExpenseOrScannedReceipt && isBetaEnabled(CONST.BETAS.NEWDOT_MANAGER_MCTEST) && selectedTab === CONST.TAB_REQUEST.SCAN && !(isOffline && isWeb),
	{

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

In IOURequestStartPage, derive the effective active tab the same way OnyxTabNavigator does — falling back to defaultSelectedTab when lastSelectedTab is absent. This ensures the tooltip's shouldShow condition correctly reflects the tab that is actually visible.

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

Lines 86 to 90 in 5ab0f25

	const [lastSelectedTab, selectedTabResult] = useOnyx(`${ONYXKEYS.COLLECTION.SELECTED_TAB}${CONST.TAB.IOU_REQUEST_TYPE}`);
	// Derive selectedTab directly instead of using state
	const selectedTab = lastSelectedTab;
	const isLoadingSelectedTab = shouldUseTab ? isLoadingOnyxValue(selectedTabResult) : false;

     // Derive selectedTab directly instead of using state
-    const selectedTab = lastSelectedTab;
+    const selectedTab = lastSelectedTab ?? defaultSelectedTab;

With this change, when no tab has been persisted to Onyx (e.g. the user's first visit, or when the stored tab name is not in the available tabs list), selectedTab falls back to CONST.TAB_REQUEST.SCAN — matching the default that OnyxTabNavigator itself uses for validInitialTab. The tooltip registration condition selectedTab === CONST.TAB_REQUEST.SCAN then correctly evaluates to true, and the tooltip is shown on the Scan tab. If the user had previously selected PER_DIEM or TIME, lastSelectedTab will carry that value and the tooltip is correctly suppressed since the Scan tab is not active.

What alternative solutions did you explore? (Optional)

N/A

[ohrytskov]

Proposal

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

When the user opens the FAB menu with the keyboard and chooses Create expense, the Scan tab becomes the visible entry point, but the Scan training tooltip does not appear even though its other prerequisites are satisfied.

What is the root cause of that problem?

The Scan tooltip is controlled by two different layers that do not share the same source of truth for the active tab:

• IOURequestStartPage registers the tooltip through useProductTrainingContext(...) only when its local selectedTab state equals CONST.TAB_REQUEST.SCAN.
• But the actual tab that is rendered as active is decided later by the tab navigator / tab bar layer, and TabSelectorItem already has its own active-tab gate (shouldShowProductTrainingTooltip && isActive).

So the page layer is making a Scan-only decision using a local selectedTab value that is initialized from lastSelectedTab and then updated asynchronously, while the tab layer separately knows which tab is actually active on screen.

In the keyboard Create expense flow, this split matters on the first mount: the Scan tab can already be the visible tab, but the page-level selectedTab === SCAN condition can still be false or stale during tooltip registration. Since useProductTrainingContext only registers the tooltip while its shouldShow argument is true, the tooltip can miss the initial Scan-tab mount for that open flow.

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

Use a single source of truth for which tab is allowed to host the tooltip, and keep that decision in the tab-rendering layer instead of the page layer.

1. In IOURequestStartPage, remove the selectedTab === CONST.TAB_REQUEST.SCAN check from the useProductTrainingContext(...) registration condition, so the tooltip registration depends only on the non-tab prerequisites (not dismissed, beta enabled, online, etc.).
2. Pass down which tab owns this tooltip explicitly (for example, CONST.TAB_REQUEST.SCAN) through OnyxTabNavigator / TabSelector.
3. In TabSelectorBase (or the equivalent tab-rendering layer), only forward shouldShowProductTrainingTooltip to the tab whose key matches that tooltip tab ID.
4. Keep the final isActive check in TabSelectorItem, so the tooltip still renders only when the Scan tab is actually the active tab.

This removes the duplicate tab-state decision from IOURequestStartPage and prevents the tooltip from depending on a page-level selectedTab value that can lag behind the tab navigator during the initial open.

What alternative solutions did you explore? (Optional)

N/A

[GCyganek]

@jponikarchuk my bad here, I just checked that this tooltip won't appear when user is in paid policy, which is true according to the test steps. Without being in paid policy it works fine:

Screen.Recording.2026-03-13.at.12.40.03.mov

So my test steps were bad and I shouldn't have added default workspace with time and per diem to prerequisites

EDIT: I updated test steps and split the test into two:

Create expense tab selector with product training tooltip:

Prerequisites: new account (Scan training tooltip not dismissed yet)

1. FAB > Create expense
2. Tap Scan
3. Verify that it correctly shows the training tooltip

Create expense tab selector full labels and working scrolling when overflowing:

Prerequisites: default workspace with enabled Time expenses and Per diem (with some rates)

1. FAB > Create expense
2. Verify that all tabs have full labels even not selected ones
   (continue on web:)
3. Narrow browser screen so that there is an overflow
4. Verify that scrolling and switching tabs works fine