为何ScrollViewer.MeasureOverride先将ComputedScrollBarVisibility设为Collapsed？

Hey there, I’ve dug into WPF’s ScrollViewer implementation before and can break down the reasoning behind this behavior:

When you set VerticalScrollBarVisibility to Auto, the ScrollViewer’s MeasureOverride method will first set ComputedVerticalScrollbarVisibility to Collapsed temporarily. After finishing an initial pass of measuring the content, it recalculates the actual visibility based on whether the content exceeds the available viewport space, then updates the property to its correct value. The exact same logic applies to the horizontal scrollbar.

Here’s why this design was chosen: #

• Layout measurement uses a "baseline first, adjust later" pattern
  WPF’s layout system operates in two core phases: Measure and Arrange. For ScrollViewer to accurately decide if scrollbars are needed, it first needs to know the content’s true required size without any scrollbar taking up space. If it reserved scrollbar width upfront, it would artificially shrink the viewport, potentially leading to false positives—showing scrollbars when the content actually fits perfectly without them. Starting with Collapsed gives a reliable baseline for content measurement.

• Avoiding a more dangerous layout loop
  While this behavior can trigger a loop when you bind to ComputedVerticalScrollbarVisibility (since the property change modifies margins which kick off another measure pass), from the ScrollViewer’s perspective, this initial Collapsed state is a safe starting point. If it assumed scrollbars were visible first, it could get stuck in a cycle where "scrollbar takes space → content needs scrolling → scrollbar must stay visible" without ever verifying if the content fits without the scrollbar.

• Working with WPF’s asynchronous layout model
  WPF handles layout updates asynchronously, and ComputedVerticalScrollbarVisibility is a dependency property whose changes trigger UI updates. This two-step approach lets the ScrollViewer incrementally converge to the correct state: first get the content’s true size, then decide if scrollbars are necessary, and finally adjust the layout accordingly. It’s a pragmatic way to resolve the layout state instead of trying to calculate everything in one single pass.

As you noted, there are workarounds for the binding-induced loop—like using delayed bindings, handling margin changes via Dispatcher to avoid immediate measure triggers, or using the ScrollChanged event to detect scrollbar visibility instead of binding directly to the property.

内容的提问来源于stack exchange，提问作者Coder14