Why a WPF ScrollViewer Does Not Scroll and How to Fix It

Overview

The WPF ScrollViewer shows scrollbars and enables scrolling when its content is larger than the available viewport.
When a ScrollViewer is placed inside a StackPanel, however, the scrollbars never appear and the content keeps growing downward regardless of how many items it holds.
This article explains that the behavior comes from how the layout system measures elements, and it organizes the container-based fixes along with the criteria for choosing between them.

Prerequisites / Environment

• Framework: .NET 6 or later / WPF
• Language: C# / XAML
• Target controls: ScrollViewer, StackPanel, Grid, DockPanel
• Architecture: applicable to both MVVM and code-behind
• Verification environment: .NET 10 / Windows 11

The tables in this article were measured in the environment above.
Each caption states how its table was measured.
The following points were confirmed in that environment:

• Inside a StackPanel 200 units tall, ScrollableHeight stays at 0 and no scrollbar appears.
• Inside a Grid or a DockPanel (LastChildFill) of the same height, the ScrollViewer receives a finite height and scrolling works. What decides this is the finite height reaching the ScrollViewer, not the container type.
• Inside a StackPanel, scrolling works once the ScrollViewer itself is given a Height.

Problem

Placing a ScrollViewer inside a vertical StackPanel and filling it with many items often results in no scrollbar; the content extends past the visible area instead.

<StackPanel>
    <TextBlock Text="Header" />
    <ScrollViewer VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</StackPanel>

Even though VerticalScrollBarVisibility="Auto" is set, the ScrollViewer expands to the full height of its content and no scrollbar is shown.

Cause / Background

The cause lies in the available size that the StackPanel passes to its children during measurement.
In its stacking direction, which is height for a vertical panel, a StackPanel measures each child with an infinite available size.
The official documentation notes that a StackPanel does not constrain its children in the direction it stacks.

A ScrollViewer shows a scrollbar only when its content is larger than the height it is given.
When the StackPanel passes an infinite height, the ScrollViewer requests exactly the height needed to fit all of its content, so no overflow occurs.
No scrollbar appears, and the ScrollViewer itself grows to the full height of its content.

The root of the problem is therefore not the ScrollViewer but the surrounding StackPanel, which never constrains the height.

The difference can be confirmed by changing only the parent layout and reading the heights off the ScrollViewer.

Measured on .NET 10 / Windows 11 with a ScrollViewer holding 40 rows of 20px each (800px total) inside a parent constrained to 200px. Nothing differs between the rows except the parent layout.

Inside the StackPanel, ViewportHeight equals ExtentHeight at 800. Although the parent is constrained to 200px, the ScrollViewer still claims the height its full content needs.
ScrollableHeight is therefore 0 and the scrollbar stays Collapsed.

With a Grid or a DockPanel, ViewportHeight settles at 200 and the remaining 600 becomes ScrollableHeight.
As the last row shows, a StackPanel produces the same result once the ScrollViewer is given an explicit height. What matters is that a constraint reaches it.

Solution

Place the ScrollViewer in a container that constrains its height.
Specifically, put it in a Grid row sized with * (star), let a DockPanel fit it into the remaining space, or give it an explicit Height or MaxHeight.
A finite height is then passed to the ScrollViewer, and a scrollbar appears once the content exceeds that height.

Implementation

Place it in a star-sized Grid row

Split the Grid into a fixed-size row and a * row that fills the remaining space, and put the scrollable ScrollViewer in the * row.

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <TextBlock Grid.Row="0" Text="Header" />

    <ScrollViewer Grid.Row="1" VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</Grid>

The * row receives the parent’s remaining height, so the ScrollViewer is given a finite height.
When the content exceeds that height, the scrollbar appears automatically.

Fit it into the remaining space with a DockPanel

A DockPanel expands its last child into the remaining area through LastChildFill, which is enabled by default.
Dock the header to the top and place the ScrollViewer as the last child.

<DockPanel>
    <TextBlock DockPanel.Dock="Top" Text="Header" />

    <ScrollViewer VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</DockPanel>

The last child without a DockPanel.Dock value fills the remaining area, so the height of the ScrollViewer is constrained.

Notes

• VerticalScrollBarVisibility="Disabled" turns scrolling off: setting Disabled prevents scrolling in that direction through user interaction.
  To hide the scrollbar while keeping scrolling, use Hidden instead.
• Avoid nesting scrollable controls directly: placing a control with its own scrolling, such as a ListBox, directly inside a ScrollViewer can make the mouse wheel act on the wrong element.
  A ListBox already scrolls internally, so it is better given a height-constrained layout, such as a * row of a Grid, than wrapped in an outer ScrollViewer.
• Physical versus logical scrolling: ScrollViewer.CanContentScroll defaults to false, giving physical, pixel-based scrolling; when it is true, scrolling is logical, by item.
  The ListBox default style sets it to true (the value source is DefaultStyle), so a data-bound ListBox scrolls logically and its VirtualizingStackPanel virtualizes items.
  Forcing CanContentScroll to false is not the only way to lose that virtualization. Counting the realized ListBoxItems of a ListBox with 2,000 items, all 2,000 were also realized with VirtualizingPanel.IsVirtualizing set to false, and with the ListBox placed inside an outer ScrollViewer or a StackPanel: when the outer element takes over scrolling or leaves the height unconstrained, the ListBox receives enough height to lay out every item. With GroupDescriptions on the CollectionView, virtualization remained as long as no GroupStyle was set. With a GroupStyle, all 2,000 were realized, and a template trigger set CanContentScroll to false.

Measured on .NET 10 / Windows 11 by showing a ListBox with 2,000 items under each condition and counting the realized ListBoxItems. The outer ScrollViewer and StackPanel are 180 high; the ListBox itself has no height in those rows.

Alternatives / Comparison

Summary

A StackPanel passes an infinite height to its children in the stacking direction, so a ScrollViewer inside it cannot detect overflow and does not scroll.
The root of the problem is the surrounding container that fails to constrain the height, not the ScrollViewer itself.

The selection criteria are as follows.

• To separate headers or footers from a variable area: place the ScrollViewer in a * row of a Grid.
  Rows can be assigned by role, which makes the layout intent explicit.
• To combine edge-docked elements with a main area: use a DockPanel and place the ScrollViewer as the last child in the remaining space.
• To cap only the height of a partial list: set MaxHeight and scroll once that height is exceeded.

In every case, the key is a layout that passes a finite height to the ScrollViewer.

• How to Prevent SelectedItems from Appearing Lost in a Virtualized WPF ListBox
• ScrollViewer (WPF Standard Control Demo App): measures the four scroll bar settings, CanContentScroll, and when the sizes are known