Company card - Long card name tooltip only appears after switching tab

[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.33-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: #95744
Email or phone of affected tester (no customers): applausetester+khcategory19@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Workspace has direct feed with card.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Company cards.
3. Assign card to any user and assign a long name to the card.
4. Hover over the card name.
   → Tooltip does not appear.
5. Switch to another tab (eg, Categories) and go back to Company cards.
6. Hover over the card name.
   → Tooltip only appears after switching tab.

Expected Result:

In Step 4, tooltip will appear when hovering over long card name.

Actual Result:

In Step 4, tooltip will appear when hovering over long card name.
In Step 6, tooltip only appears after switching tab.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7204912_1783703700044.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7204912

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

[melvin-bot]

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

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

TextWithTooltip (web) decides whether to render its tooltip only inside the Text onLayout callback, by comparing the DOM node's scrollWidth/scrollHeight against offsetWidth/offsetHeight to detect truncation — see TextWithTooltip/index.tsx:24-34. onLayout fires once on mount and there is no re-measure afterward.

On the first render of the Company cards tab, the row is laid out before the table column widths finish settling, so at the moment onLayout fires scrollWidth is not yet greater than offsetWidth. The truncation check returns false, showTooltip stays false, and hovering never re-triggers onLayout — so no tooltip appears. Switching to another tab and back forces a fresh layout pass at the final, correct width; onLayout fires again, the overflow check now passes, and the tooltip appears.

PR #95744 didn't introduce this measurement logic (it's pre-existing in the shared component) — it exposed it by using TextWithTooltip shouldShowTooltip inside a tab-hosted table where this initial-layout width race occurs (see WorkspaceCompanyCardsTableRow.tsx:151-186). This is web-only; the native variant has no tooltip/measurement.

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

Make TextWithTooltip re-measure after layout settles instead of relying on a single onLayout firing at mount. Options, in order of preference:

1. Measure via a ref inside a useLayoutEffect (in addition to onLayout), re-running when text/numberOfLines change, so the check runs after the element reaches its final width.
2. Or attach a ResizeObserver to the text node so the overflow check re-evaluates whenever the width changes (covers the tab-switch/resize case generically).

Because TextWithTooltip is a shared component, verify the fix doesn't regress its other existing usages.

If a component-level fix is considered too risky for a deploy blocker, the fast mitigation is to revert PR #95744 (it only adds tooltips to the company card table) and re-land it once TextWithTooltip re-measures reliably.

What alternative solutions did you explore? (Optional)

Considered scoping the fix to the table row (e.g. forcing a re-render key), but the root cause is in the shared component's single-shot measurement, so fixing it there resolves the class of bug rather than one call site.

Investigation details & confidence

• Confidence: High. The mechanism is confirmed by reading the component source; the tab-switch-fixes-it symptom matches a scrollWidth <= offsetWidth-at-mount → re-layout-on-return sequence exactly.
• What was ruled out: styles.pre vs explicit numberOfLines={1} — not relevant. numberOfLines defaults to 1 at index.tsx:12, so all four new usages are single-line and share the identical measurement path.
• Why other TextWithTooltip usages work: they aren't mounted inside a tab whose column widths resolve after the first layout pass, so onLayout measures the truncating width the first time.
• Confirmation path (no backend logs needed): log scrollWidth/offsetWidth inside onLayout on first render vs after a tab switch in DevTools.

---

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