[Bug]: Tooltip permanently hidden inside tightly-fitted overflow:hidden containers (regression in 9.10.4+)

Library

React Components / v9 (@fluentui/react-components)

Bug Description

Actual Behavior

On @fluentui/react-tooltip 9.10.4+ (following #36386, which fixed #32882), a Tooltip whose trigger sits inside a tightly-fitted overflow: hidden container never appears at all — even at rest, with no scrolling involved.

Repro:

<div style={{ overflow: 'hidden', display: 'flex' }}>
  <Tooltip content="I never appear on 9.10.4+" relationship="label">
    <Button>Hover me</Button>
  </Tooltip>
</div>

On 9.10.3 the tooltip appears as expected. On 9.10.4+ it never does.

Expected Behavior

The tooltip should still appear when the trigger and tooltip are both within/adjacent to a tightly-fitted overflow container, as long as they aren't actually clipped/scrolled out of view.

Root Cause

In packages/react-components/react-positioning/library/src/usePositioningOptions.ts, the hide middleware is added without a boundary option:

hideMiddleware({ strategy: 'referenceHidden' }),
hideMiddleware({ strategy: 'escaped' }),

Unlike shift/flip, which are given the same container/overflowBoundary config, hide falls back to floating-ui's default boundary of 'clippingAncestors'. This means it walks up from the trigger to any ancestor with overflow: hidden/scroll/auto, not just genuine scroll containers that are actually clipping content.

In the repro above, the wrapping <div style={{ overflow: 'hidden', display: 'flex' }}> hugs the button tightly with no extra space above it. Since Tooltip defaults to position="above", the computed tooltip position extends past that div's clip box on the very first render — no scrolling required. escaped becomes true immediately and stays that way, so the tooltip never shows (see setHidden(escaped || referenceHidden) in useTooltipBase.tsx).

Impact

Any trigger inside a tightly-fitted overflow: hidden (or scroll/auto) container — flex toolbars, truncated table/list cells, card layouts, etc. — silently loses its tooltip permanently, regardless of scroll position. This is a very common CSS pattern, so this likely affects many consumers upgrading past 9.10.4.

Proposed Fix

Pass the same container/overflowBoundary used by shift/flip into both hideMiddleware calls, so escape/hidden detection is scoped consistently with the rest of the positioning logic instead of picking up incidental non-scrolling clip ancestors.

Related Issue(s)

• Regression introduced by #36386 (fix for #32882)

Are you willing to submit a PR to fix?

yes

cc @charles-izzi