[Bug]: Navigating between views in People Tab freezes Outlook. Infinite overflow re-measure loop in contact-list row "+N more" menus

[asthatripathi17]

Component

Overflow

Package version

9.74.4

React version

18.3.1

Environment

System:
  OS: macOS 26.6.1
  CPU: (12) arm64 Apple M3 Pro
Browsers:
  Edge: 151.0.4129.93
  Safari: 26.6
npmPackages:
  @fluentui/react-components: 9.74.4
  @fluentui/priority-overflow: 9.4.1 (transitive)
  @fluentui/react-overflow: 9.9.1 (transitive)
  react: 18.3.1
  react-dom: 18.3.1
  @types/react: 18.x
  @types/react-dom: 18.x
Repro host: StackBlitz (WebContainer, in-browser)

Current Behavior

We use Fluent v9 <Overflow> for the actions/metadata in contact-list rows: a "+N more" menu built with useOverflowMenu that mounts only when items overflow. In the app this intermittently pegs the CPU and freezes the whole tab. The visible trigger is navigating between views, but the underlying cause is an unbounded re-measure loop in the overflow manager.

Minimal reproduction: a short list of <OverflowItem>s in a fixed-width container with a conditionally-mounted "+N more" menu. At a container width near the boundary where the last item flips between fitting and not fitting, the overflow manager never converges. In the StackBlitz the on-screen "Renders so far" counter climbs continuously with no user interaction and never stops, showing the loop never settles even at rest.

What appears to happen:

• Mounting/unmounting the "+N more" menu changes the available width, which the manager recomputes eagerly (behavior added in fix(react-overflow,priority-overflow): correct overflow snapshot on first paint #36264), flipping the fit decision back and forth.
• The hooks subscribe directly to the manager snapshot (refactor(react-overflow,priority-overflow): subscribe model removes intermediate state from <Overflow> #36263), so every manager recomputation drives a React re-render, which re-measures, which dispatches again.
• ResizeObserver re-fires on the manager's own show/hide, feeding the loop.
• There is no convergence cap: processOverflowItems is trusted to settle, and the debounced forceUpdate only coalesces within a microtask; it does not bound iterations.

Performance trace of one ~7.5s freeze (attached):

• ~17,700 overflow measurements, ~12,600 forced layouts, ~13,300 removeChild
• DOM nodes 8.5k -> 37.5k, event listeners 51k -> 78k, JS heap 160 -> 470 MB
• 0 frames painted during the freeze (GC was only ~63 ms, so this is not GC pressure)
• Hottest leaf is getElementAxisSize (synchronous offsetWidth/offsetHeight reads) at ~26% self-time, called from processOverflowItems in priority-overflow's overflowManager.

Regression range: this path appears to originate in @fluentui/react-overflow@9.9.0 / @fluentui/priority-overflow@9.4.0 (PRs #36263 and #36264). #36401 (react-overflow 9.9.1 / priority-overflow 9.4.1) fixed the unmount/teardown notification path only, so this mounted-oscillation path still reproduces. This is likely related to the still-open #36584 (Teams web), but that report is the unmount-during-navigation path and has no repro; this issue is the mounted boundary-width oscillation and includes a minimal repro.

Expected Behavior

Overflow measurement should converge after a bounded number of passes. At a boundary width the visible/overflow split should settle to a stable state (showing "+N more" or not), not oscillate forever. Mounting/unmounting the overflow menu should not be able to drive an unbounded measure -> render loop, and the component should never be able to freeze the host app. A per-frame cap (or hysteresis) on re-measure passes would bound it.

Reproduction

https://k5fbgvri.stackblitz.io

Steps to reproduce

1. Open the StackBlitz reproduction.
2. Watch the "Renders so far" counter. At the default container width it climbs continuously on its own with no user interaction and never stops. The overflow manager re-measures and re-renders in an unbroken loop instead of settling.
3. Optional: slowly resize the container width. The counter keeps climbing across widths; there is no width at which it converges to a stable render count.

Are you reporting an Accessibility issue?

None

Suggested severity

Urgent - No workaround and Products/sites are affected

Products/sites affected

Outlook - People tab (contact list rows)

Are you willing to submit a PR to fix?

no

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[asthatripathi17]

Here's a screen recording from StackBlitz

Screen.Recording.2026-08-20.at.10.46.10.AM.mov

[bsunderhus]

Hey there Astha Tripathi (@asthatripathi17) , I can't seem to be able to open the repro link https://k5fbgvri.stackblitz.io/, do you have it in any other environment perhaps?!

[bsunderhus]

Here's another stackblitz link: https://stackblitz.com/edit/k5fbgvri?file=src%2FApp.tsx

[bsunderhus]

This is most definitely a symptom of the same problem reported here #36584, Paolo Aliprandi (@paolo-aliprandi), Let's keep both on track. I'll be following up with PRs related to both of them