Copilot - No tooltip in landscape, wrong tooltip position after rotating to portrait

[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.32-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: #93393
Email or phone of affected tester (no customers): sidbhisdhidhisdhis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: User Settings

Action Performed:

Precondition:

• User has copilot account to another account.

1. Launch Expensify app.
2. Go to Account.
3. Rotate device to landscape.
4. Rotate device to portrait.

Expected Result:

• Account switcher tooltip will appear in landscape mode.
• Account switcher tooltip will appear under Switch button after rotating device to portrait mode.

Actual Result:

• Account switcher tooltip does not appear in landscape mode.
• Account switcher tooltip does not appear under Switch button after rotating device to portrait mode.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203706_1783595794125.Screen_Recording_20260709_191333_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7203706

Issue Owner

Current Issue Owner: @wildan-m

[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/7eaf53e791290854430ed9143004d8be42e4c783f1d729935389c575ec88fb99

[melvin-bot]

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

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

On native, the tooltip anchored to the Switch button measures the anchor's screen position once and never re-measures it when the device rotates. There is no Dimensions/orientation change listener anywhere in the Tooltip tree, and the one "re-render after viewport change" path is gated behind isResizing, which is hardcoded to false on native:

• The resize-driven re-measure only runs if (isResizing) → BaseEducationalTooltip.tsx:91-106
• useIsResizing always returns false on native → useIsResizing/index.native.ts

The tooltip is rendered in an absolutely-positioned Portal from the cached xOffset/yOffset, so with a stale measurement:

• Portrait → landscape: the old offsets fall outside the new (wider) window, the off-screen guard hides it, and nothing re-shows it → no tooltip in landscape.
• Landscape → portrait: the portal renders at the last-known coordinates, which no longer sit under the Switch button → wrong position.

This is a pre-existing native tooltip limitation, not something PR #93393 introduced — but PR #93393 exposed it by anchoring a persistent educational tooltip to the header with shouldHideOnNavigate: false, which prevents the stale tooltip from being dismissed on rotation.

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

Make the native tooltip re-measure its anchor on orientation change. In BaseEducationalTooltip, subscribe to Dimensions.addEventListener('change', …) (or an orientation listener) while the tooltip is shown, and re-run renderTooltip() so the anchor is re-measured and the portal repositioned. Equivalent alternatives: give useIsResizing a real native implementation driven by dimension changes so the existing isResizing re-render path fires, or key the re-measure effect on useWindowDimensions().

Investigation details, alternatives & confidence

• Anchor is measured via .measure() in EducationalTooltip/measureTooltipCoordinate, triggered from the child's onLayout and the delayed-show effect. On rotation the wrapper <View>'s own box often doesn't change size (only its screen x/y), so onLayout may not re-fire.
• GenericTooltip does read useWindowDimensions() (updates on rotation) and re-runs getTooltipStyles, but the anchor xOffset/yOffset are only refreshed by updateTargetBounds, which only fires from a fresh .measure() — so window-size updates alone don't fix position.
• Alternative explanation considered: rotating could cross the narrow→wide responsive breakpoint (800px) and change the header layout. On an S25 FE phone, landscape width stays below 800px, so the layout stays narrow — this isn't the cause.
• Confidence: High on the structural root cause (no native orientation re-measurement). Medium on exactly which sub-mechanism dominates symptom (a) — the off-screen hideTooltip guard vs. simply never re-showing — which depends on runtime layout values.
• Note for BugZero: this is an edge case (rotating the device while the one-time educational tooltip is visible) in a brand-new feature. If a same-day fix isn't practical, it may be a reasonable candidate to demote from deploy-blocker severity rather than revert PR Make Copilot switching discoverable with a dedicated Switch button on the Accounts page #93393.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[inimaga]

@wildan-m Can you look into this.

cc: @eh2077