[$125] Test Drive - Not functional tooltip on test drive expense submission

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: v9.1.51-0
Reproducible in staging?: Yes
Reproducible in production?: Unable to check - new feature testing
If this was caught during regression testing, add the test name, ID and link from TestRail: #60997
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Mac 14.5/ Chrome
App Component: Other

Action Performed:

1. Navigate to https://staging.new.expensify.com

2. Create a new public account

3. Choose anything but "Manage my team's expenses" to reach the test drive modal

4. Enter a valid email on the email field and click on "Start test Drive"

5. After being directs to the expense submission page

6. Click on the tooltip above the "create" button

Expected Result:

Clicking on tooltip creates the expense

Actual Result:

Clicking on tooltip is not functional.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6841054_1748077573580.Screen_Recording_2025-05-24_at_11.43.45_in_the_morning.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021927605626835916376
• Upwork Job ID: 1927605626835916376
• Last Price Increase: 2025-05-28

Issue Owner

Current Issue Owner: @

[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.

[melvin-bot]

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

[melvin-bot]

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

[nkdengineer]

Proposal

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

Clicking on tooltip is not functional.

What is the root cause of that problem?

This tooltip has no onTooltipPress prop then nothing happens when clicking on this tooltip.

App/src/components/MoneyRequestConfirmationList.tsx

Line 1006 in 26cd22c

<EducationalTooltip

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

We should add onTooltipPress={() => confirm(undefined)} here

App/src/components/MoneyRequestConfirmationList.tsx

Line 1006 in 26cd22c

<EducationalTooltip

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None

What alternative solutions did you explore? (Optional)

We can display the cursor default if there is no tooltip press action. To do that we should remove the default value of onTooltipPress prop here and here

Then we apply the cursor default style here if onTooltipPress is undefined. Do the same for native file

style={[rootWrapperStyle, animationStyle, !onTooltipPress && styles.cursorDefault]}

App/src/components/Tooltip/BaseGenericTooltip/index.tsx

Line 174 in 352de72

style={[rootWrapperStyle, animationStyle]}

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ChavdaSachin]

Proposal

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

Tooltip not functional on test drive expense submission.

What is the root cause of that problem?

We do not handle onTooltipPress here.

App/src/components/MoneyRequestConfirmationList.tsx

Line 1006 in a76fe90

<EducationalTooltip

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

Import hideProductTrainingTooltip here and pass onTooltipPress = {hideProductTrainingTooltip} to the EducationalTooltip component` this will hide the tooltip when pressed.

App/src/components/MoneyRequestConfirmationList.tsx

Line 248 in a76fe90

const {shouldShowProductTrainingTooltip, renderProductTrainingTooltip} = useProductTrainingContext(

App/src/components/MoneyRequestConfirmationList.tsx

Line 1006 in a76fe90

<EducationalTooltip

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[fabioh8010]

Hmm not sure if this one is a valid bug, just checked the Design and Manual Tests doc and there are no mentions that this tooltip should be clickable. Curious what you think @marcaaron @danielrvidal

[PiyushChandra17]

🚨 Edited by proposal-police: This proposal was edited at 2025-05-26 21:37:30 UTC.

Proposal

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

Test Drive - Not functional tooltip on test drive expense submission

What is the root cause of that problem?

When we create a public acount by default shouldShowSettlementButton is false, hence ButtonWithDropdownMenu is triggered to create an expense. Now this button takes onPress which never gets triggered when clicking on tooltip that is the reason it is non functional.

onTooltipPress props is missing here, Perhaps this is the root cause

App/src/components/MoneyRequestConfirmationList.tsx

Lines 1006 to 1016 in 41956a9

	<EducationalTooltip
	shouldRender={shouldShowProductTrainingTooltip}
	renderTooltipContent={renderProductTrainingTooltip}
	anchorAlignment={{
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.CENTER,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
	}}
	wrapperStyle={styles.productTrainingTooltipWrapper}
	shouldHideOnNavigate
	shiftVertical={-10}
	>

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

We should explicitly pass onTooltipPress set to confirm so that when we press on tooltip it creates an expense

<EducationalTooltip
    shouldRender={shouldShowProductTrainingTooltip}
    renderTooltipContent={renderProductTrainingTooltip}
    anchorAlignment={{
        horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.CENTER,
        vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.BOTTOM,
    }}
    wrapperStyle={styles.productTrainingTooltipWrapper}
    shouldHideOnNavigate
    shiftVertical={-10}
    onTooltipPress={confirm}
>

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Or we can pass onTooltipPress prop set to {(event, value) => confirm(value as PaymentMethodType)} on <EducationalTooltip />

 onTooltipPress={(event, value) => confirm(value as PaymentMethodType)}

Result

tooltip_functional.mp4

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[marcaaron]

I think this is a wontfix and we should close it unless someone reports this internally.

[marcaaron]

Though actually maybe the only thing we need to change is the cursor pointer on hover. I just tried it and it does seem like something that would be "clickable" which is misleading.

[techievivek]

Ok, cool, we can update the cusor type here then.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Upwork job price has been updated to $125

[nkdengineer]

Updated proposal

• Add alternative solution with another expected.

[fabioh8010]

I think @nkdengineer alternative solution looks good if we want to just make the tooltip not clickable if no onTooltipPress was provided, but we need to have two things in mind:

1. This change might affect other tooltips around the codebase, so let's be careful.
2. When hovering over the X button, the cursor pointer should stay the same (clickable).

[nkdengineer]

@fabioh8010

1. The x button is always clickable because it dismisses the tooltip.
2. We can see that the onTooltipPress is undefined for other tooltips then I think it's safe with the cursor style. To safer we can also add the isEducationTooltip for this style.

[techievivek]

I think we can go ahead and just close this. The current cursor type is set to pointer, which makes sense as it implies interactivity, similar to closing the tooltip via the 'x' button in the top-right corner. And if we ever introduce an onTooltipPress action in the future, having the pointer cursor will help visually indicate that the tooltip is clickable.

[nkdengineer]

@techievivek I think we should display the default pointer for the tooltip that doesn't have onTooltipPress because it's not clickable. With this education tooltip, only X button is clickable because it will close the tooltip. It will differentiate from clickable (we're having some clickable tooltips, we can search this via onTooltipPress=). tooltips If we introduce onTooltipPress in the feature, the cursor will be changed to pointer.

[marcaaron]

Agree with @nkdengineer. It's a small thing, but having pointers for non-interactive elements is a bad practice.

[danielrvidal]

I'm good with the update if that follows our other tooltips. I think it makes sense to make it consistent.

[linhvovan29546]

Proposal

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

Test Drive - Not functional tooltip on test drive expense submission

What is the root cause of that problem?

We use AnimatedPressableWithoutFeedback as the pressable component for BaseEducationalTooltip. This is an animated wraper of PressableWithoutFeedback.

App/src/components/Tooltip/BaseGenericTooltip/index.tsx

Line 161 in 09de15b

const AnimatedWrapper = isEducationTooltip ? AnimatedPressableWithoutFeedback : Animated.View;

App/src/components/AnimatedPressableWithoutFeedback.tsx

Line 4 in 09de15b

const AnimatedPressableWithoutFeedback = Animated.createAnimatedComponent(PressableWithoutFeedback);

And inside the nested component BaseGenericPressable, the interactive prop defaults to true. As a result, the BaseGenericPressable returns the cursorPointer style when interactive is true.

App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

Line 39 in 09de15b

interactive = true,

App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

Lines 71 to 82 in 09de15b

	const cursorStyle = useMemo(() => {
	if (!interactive) {
	return styles.cursorDefault;
	}
	if (shouldUseDisabledCursor) {
	return styles.cursorDisabled;
	}
	if ([rest.accessibilityRole, rest.role].includes(CONST.ROLE.PRESENTATION) && !isNested) {
	return styles.cursorText;
	}
	return styles.cursorPointer;
	}, [interactive, shouldUseDisabledCursor, rest.accessibilityRole, rest.role, isNested, styles.cursorPointer, styles.cursorDefault, styles.cursorDisabled, styles.cursorText]);

This causes the tooltip to incorrectly show a pointer cursor (cursor: pointer), even though the tooltip is not actually clickable.

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

We should:

• Remove the default value of onTooltipPress from both BaseGenericTooltip and GenericTooltip:
  

  App/src/components/Tooltip/BaseGenericTooltip/index.tsx

  Line 45 in 09de15b

  onTooltipPress = () => {},

function GenericTooltip({
....
    onTooltipPress,
}: GenericTooltipProps)
....

function BaseGenericTooltip({
  .....
    onTooltipPress,
}: BaseGenericTooltipProps) {

• Then set interactive={false} when isEducationTooltip is true and onTooltipPress is undefined:
  

  App/src/components/Tooltip/BaseGenericTooltip/index.tsx

  Line 161 in 09de15b

  const AnimatedWrapper = isEducationTooltip ? AnimatedPressableWithoutFeedback : Animated.View;

            <AnimatedWrapper
                interactive={isEducationTooltip ? !!onTooltipPress : undefined}
                ref={viewRef(rootWrapper)}
                style={[rootWrapperStyle, animationStyle]}
                onPress={isEducationTooltip ? onTooltipPress : undefined}
                role={isEducationTooltip ? CONST.ROLE.TOOLTIP : undefined}
                accessibilityLabel={isEducationTooltip ? CONST.ROLE.TOOLTIP : undefined}
            >

This ensures the tooltip won’t show the pointer cursor when it’s not meant to be interactive.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None, UI bug

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[techievivek]

It will differentiate from clickable (we're having some clickable tooltips, we can search this via onTooltipPress=)

Ok, I see. Since the prop is defined for some tooltips, it makes sense to use the default pointer cursor when the prop isn't provided. That way, we can visually distinguish between tooltips that are clickable and those that aren’t.

[techievivek]

@Ollyws can you review the proposals above? Thanks.

[Ollyws]

@nkdengineer's proposal LGTM.
🎀👀🎀 C+ reviewed

[melvin-bot]

Current assignee @techievivek is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[linhvovan29546]

@Ollyws Why did you choose to pass cursorDefault directly to the tooltip style in the selected proposal? This feels like a workaround than addressing the root cause. Wouldn't it be more appropriate to handle this through the interactive prop instead? We already have logic for that at the base component level, and it's a pattern we've used consistently throughout the app. cc @techievivek

[Ollyws]

@linhvovan29546 Thanks for your proposal but I went with @nkdengineer's proposal because yours is in concept essentially the same, and it would be unfair to pass over @nkdengineer's proposal due to some implementation details, in my opinion.

If @techievivek thinks those implementation details are important then maybe we could implement them and come to some kind of arrangment in terms of compensation.