Skip to content

fix(react): use exact width for Sticky placeholder - #36487

Draft
AKnassa wants to merge 1 commit into
microsoft:masterfrom
AKnassa:ak-issue-29383-sticky-width-rounding
Draft

fix(react): use exact width for Sticky placeholder#36487
AKnassa wants to merge 1 commit into
microsoft:masterfrom
AKnassa:ak-issue-29383-sticky-width-rounding

Conversation

@AKnassa

@AKnassa AKnassa commented Aug 1, 2026

Copy link
Copy Markdown

Previous Behavior

Inside a ScrollablePane, sticky headers sometimes made a horizontal scrollbar appear when nothing actually overflowed — most often under browser zoom. Scrolling back to the top made the scrollbar vanish, which looked like a glitch. Cause: the sticky placeholder's width was computed from browser measurements that are rounded to whole pixels, so it could come out 1–2px wider than the real content.

New Behavior

No phantom scrollbar. When the content doesn't genuinely overflow sideways, the placeholder now uses the exact fractional width of the content. Content that really does overflow keeps the old calculation, so nothing else changes.

What changed

  • One targeted branch in the Sticky component's placeholder width computation.
  • A red-first test that reproduces the rounding error (expected 701.6px, got 702px before the fix) and a guard test pinning the old behavior for genuinely overflowing content.
  • A change file for the release notes.

Sticky and ScrollablePane suites are green with no snapshot changes. One note for reviewers: the exact-width path measures post-transform size, so apps scaling content with transform: scale() get the scaled width — the measurement the issue reporter themselves proposed.

Related Issue(s)

Sticky computed its placeholder width as scrollWidth +
(offsetWidth - clientWidth). All three DOM properties are rounded to
integers while the true layout width can be fractional (typically
under browser zoom), so the placeholder could end up 1-2px wider
than the content, making ScrollablePane show a phantom horizontal
scrollbar that disappears after scrolling back to the top.

When the content has no genuine horizontal overflow
(scrollWidth <= clientWidth), use the exact fractional
getBoundingClientRect().width instead. Content that really
overflows keeps the previous computation.

Red-first test locks both branches: fractional width is used when
nothing overflows, the legacy sum when it does. Sticky and
ScrollablePane suites green with no snapshot churn.

Fixes microsoft#29383
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: numerical error in Sticky width calculation causes unnecessary horizontal scroll bar

1 participant