Expense - "Auto-update" tooltip is not visible on landscape mode.

[applause-bot]

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.4.26-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93555
Email or phone of affected tester (no customers): applausetester+ib0024@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: Use an expensifail account.
Prerequisite 2: User is owner of a workspace with "Distance Rates" enabled.
Prerequisite 3: Two custom rates created:

• Rate A: $0.67/mi, valid Jul 1 – Jul 10, 2025
• Rate B: $0.70/mi, valid Jul 1 – Jul 10, 2026

1. Open the Expensify app.
2. Navigate to workspace chat.
3. Start creating a map distance expense.
4. Change date to "Jul 1, 2025"
5. Note that rate is automatically updated to "Rate A", and "Auto-update" tooltip, appears on "Rate" field.
6. Turn to landscape mode.
7. Scroll down to "Rate" field.
8. Note that tooltip is no longer visible.
9. Return to portrait mode.
10. Note that tooltip reappears.

Expected Result:

"Auto-Update" tooltip after rate is updated, should be visible when switching to landscape mode.

Actual Result:

"Auto-Update" tooltip after rate is updated, disappears after switching to landscape mode.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7197000_1782943161157.Invalid_8.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Rizky Gunawan
Bug ID: 7197000

Issue Owner

Current Issue Owner: @GCyganek

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/4de31b5b4f7f7cebf2d35f4e9c89631f71d37e8bf27cec2476cbb5be2850c757

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #93555

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Auto-update" tooltip is an educational tooltip (useProductTrainingContext(MILEAGE_RATE_AUTO_UPDATED)) rendered on the Rate field. It is not hidden by any product-training / narrow-layout gate — that config is shouldShow: () => true (TOOLTIPS.ts:79-84).

The disappearance comes from the "scrolled out of view" viewport-bounds check inside renderTooltip in BaseEducationalTooltip.tsx:60-82:

const availableHeightForBottom = dimensions.height - (bottom + variables.bottomTabHeight - offset);
...
if (availableHeightForTop < 0 || availableHeightForBottom < 0 || ...) { hideTooltip(); } else { showTooltip(); }

This reserves a fixed bottomTabHeight (72px) below the anchored field, measured against the raw window height. On rotation, the safe-area insets/layout change re-fire renderTooltip. In landscape the window height is much smaller, so for a Rate field sitting low in the confirmation list, bottom + bottomTabHeight exceeds dimensions.height → availableHeightForBottom < 0 → hideTooltip(). Rotating back to portrait restores the height, the check passes, and it shows again.

This was introduced with the tooltip + shouldHideOnScroll wiring in PR #93555 (RateField.tsx:96-151).

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

Fix the viewport-bounds check in BaseEducationalTooltip.tsx so it doesn't misclassify an on-screen field as off-screen in landscape:

• The confirmation screen has no bottom tab bar, so reserving a hardcoded variables.bottomTabHeight (72px) below the anchor is incorrect here. The bottom reservation should reflect the actual scroll container / footer, or be zero when there is no bottom tab — rather than a fixed device-independent constant applied against the shorter landscape window.
• Concretely: measure available space against the anchored scroll container's visible bounds (not raw Dimensions.get('window') minus fixed header/tab heights), or make the reserved header/footer heights configurable per-consumer so the Rate field on the confirmation list reserves the correct footer height.

Because this bounds check is shared by every shouldHideOnScroll educational tooltip, please verify the change doesn't regress the intended scroll-hide behavior on other surfaces.

Supporting evidence (App HEAD ee63944, confidence: High)

• Hide decision: BaseEducationalTooltip.tsx:60-82 — availableHeightForBottom = dimensions.height - (bottom + bottomTabHeight - offset) goes negative in landscape.
• Re-trigger on rotation: renderTooltip depends on insets.* (line 83); the resize effect (lines 85-100) re-runs it when orientation changes.
• Not the product-training gate: TOOLTIPS.ts:79-84 — MILEAGE_RATE_AUTO_UPDATED has shouldShow: () => true, so shouldShowProductTrainingTooltip does not flip on rotation.
• Consumer wiring: RateField.tsx:142-150 passes shouldHideOnScroll, routing this tooltip through the bounds check via MenuItem.tsx:847-851.

Alternatives considered & ruled out: narrow-layout/shouldUseNarrowLayout gating (config ignores it); the native resize branch hiding it (useIsResizing is always false on native, so the hide is the bounds check, not the resize path). State is not lost — the tooltip reappears in portrait — which is consistent with a pure geometry-based hide, not a dismissal.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95161) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[thelullabyy]

I think we can demote this...

[thelullabyy]

@Krishna2323 Could you please check this one?