Fix InitialItemIndex viewport underfill for small items in big container or on window resize

[ilonatommy]

Fixes #67933

Problem

Virtualize<TItem> lets you load a list form a given InitialItemIndex instead of index 0. The component seeds a window of items around that index using a rough guess of item height, then relies on the browser's IntersectionObserver/spacer callbacks to detect whether the viewport is actually filled and grow the window if not.

The bug: once the initial guess placed the window near the end of the list (or items were smaller than assumed, or the container was unusually tall/resized), the "did we fill the viewport" check could be satisfied or short-circuited prematurely. The result: only a small strip of real rows rendered, with visible empty gaps above and/or below the viewport that a user scroll (not a resize/re-render) was needed to fix.

Fix

AlignToItemAsync now returns the post-alignment viewport state: covered, before spacer visible, or after spacer visible. Virtualize<TItem> uses that browser-measured result to grow the rendered window geometrically in the required direction while preserving target alignment.

Initial-index positioning repeats this align-and-grow cycle until real content covers the viewport or no further growth is possible. ScrollToItemAsync performs the same immediate viewport-growth check after scrolling, with subsequent filling handled by the existing spacer observers. Growth remains bounded by the list size and MaxItemCount plus overscan.

viewport-fill.mp4

[Copilot]

Pull request overview

This PR fixes a Blazor Virtualize/QuickGrid startup issue where small InitialItemIndex values could leave the viewport bottom underfilled until the user scrolls. It does this by deferring “leading overscan” (items reserved above the target) until the component has received its first spacer/measurement feedback, and adds E2E coverage to prevent regressions.

Changes:

• Add a _hasSpacerFeedback flag to detect when initial spacer observer feedback has occurred and use it to avoid reserving pre-target overscan during the initial unmeasured window seed.
• Mark spacer feedback as received when OnBeforeSpacerVisible/OnAfterSpacerVisible run, restoring the normal overscan-before-target behavior after measurement.
• Add E2E tests asserting that both QuickGrid and Virtualize fill the viewport for small InitialItemIndex values (including a small overscan scenario), plus minor test-asset updates to support the scenario.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/Components/Web/src/Virtualization/Virtualize.cs	Defers leading overscan until spacer feedback exists to prevent initial viewport underfill.
src/Components/test/testassets/BasicTestApp/VirtualizationAnchorMode.razor	Adds a UI toggle to set a small overscan to reproduce/validate the scenario.
src/Components/test/testassets/BasicTestApp/QuickGridTest/QuickGridScrollComponent.razor	Adjusts rendered item styling in the scroll/initial-index test component used by E2E coverage.
src/Components/test/E2ETest/Tests/VirtualizationTest.cs	Adds E2E assertions ensuring initial-index loads cover the viewport bottom with real items for both QuickGrid and Virtualize.

[MayaKirova]

Not sure if this is something that needs an outsider's review, but I did spend some time looking into the Virtualization Component (partly out of curiosity because we do also have virtualization in the IgniteUI components) so decided to give it a go. :)

[ilonatommy]

Thank you for the review. I will draft it now since this PR will wait for #68114 to get in first - this PR changes are stacked on 68114.

[PureWeen]

Disclosure: This review was produced with assistance from GitHub Copilot. The browser reproduction and instrumentation described below were run against the current PR head before posting.

I found a near-end case that still underfills on the current head (8ffabe54).

Using the real Interactive Server browser path in Chrome (not synthetic callback injection):

• 2,000 items
• ItemSize=50
• default OverscanCount=15 and MaxItemCount=100
• 2,500px-tall container
• InitialItemIndex=1990

The provider is called once with Count=31, only items 1975-1999 render, and roughly half the viewport remains blank above them. Both spacer elements end up geometrically inside the viewport, the bottom is covered, and the top is not. The matched InitialItemIndex=1950 control works: it requests 31,82, renders 1918-1999, and covers both edges.

The trace does not show the same-batch bothSpacersIntersect guard causing this. The before-spacer callback occurs during programmatic scrolling and is ignored while _currentScrollCts is active. Scrolling then clamps at the end, so the already-intersecting before spacer does not produce another transition. The after spacer has zero height and its callback is skipped. The window therefore never grows or shifts backward.

Can we extend the fix so that when initial positioning clamps near the end and forward growth cannot fill the viewport, it expands or shifts the window backward while keeping the target visible?

I think the regression coverage should include the 2,000-item/index-1990 case paired with index 1950 as a positive control, asserting that both viewport edges are covered without user scrolling and that requests terminate. It would also be worth covering both ItemsProvider and in-memory Items, plus QuickGrid if it shares this path.

[kotlarmilos]

LGTM, thanks!

[PureWeen]

Disclosure: This review was produced with assistance from GitHub Copilot. The browser reproduction and instrumentation below were run against the current PR head, ab1e067c.

Thanks for iterating on this. The latest change fixes the original initial-load underfill in my exact 2,000-item / InitialItemIndex=1990 browser repro. It now requests 31,62, renders through item 1999, and covers both viewport edges.

I did find a deterministic resize regression on the same path though. With fixed 50px items and a 2,500px container, the first visible item starts at 1950. After resizing the container to 2,000px and back to 2,500px, it moves to 1362 and stays there. The index-1950 control similarly moves to 1751. On the previous head, that control stayed at 1950 through both resizes.

The instrumented trace shows an out-of-order rendered-content measurement:

1. JS measures 25 rendered items with a 1,250px separation.
2. Pending growth commits a 62-item window before that fire-and-forget callback reaches .NET.
3. .NET consumes the old 1,250px value while _lastRenderedItemCount is already 62.
4. RecalibrateItemSize changes _itemSize from 50 to 20.161291, and the effective measured height becomes 28.735632.
5. The next correct 62-item / 3,100px measurement only brings the polluted running average to 37.583893. The before spacer is then about 55,689px instead of roughly 96,900px, so the next resize redistributes to the wrong part of the list.

Can we preserve the rendered-window identity with the measurement, or otherwise reject/supersede a measurement once the rendered slice has changed? I tried awaiting the measurement as a diagnostic, but tiny floating-point changes caused repeated alignment work, so I don't think that is the right production fix by itself.

I think the regression assertion should verify that the initial anchor remains stable through resize smaller and larger, not only that both viewport edges are covered. It should keep the 1990 case paired with the 1950 control and cover Items, ItemsProvider, and QuickGrid. The current Mono Server QuickGrid in-memory case is also red in build 1561049, so that should stay part of the validation rather than weakening its item-950 assertion.

[ilonatommy]

I did find a deterministic resize regression on the same path though. With fixed 50px items and a 2,500px container, the first visible item starts at 1950. After resizing the container to 2,000px and back to 2,500px, it moves to 1362 and stays there. The index-1950 control similarly moves to 1751. On the previous head, that control stayed at 1950 through both resizes.

That's a resize of container scenario after the requested item is correctly aligned to the top of the viewport and the alignment process finishes. I think it's out of scope for this PR and maybe in general for virtualize component. We don't promise that jump will survive the resize.

The CI failure of QuickGrid_InitialIndex_TallContainer_NearEnd_FillsViewportWithoutUserScroll is a flaky test, I have a 1/21 failure rate reproduction and I am looking into it.

[ilonatommy]

/backport to release/11.0-rc1

[github-actions]

Started backporting to release/11.0-rc1 (link to workflow run)

[PureWeen]

Human + Copilot disclosure: This reply comes from a joint review by Shane Neuville and GitHub Copilot.

We don't promise that jump will survive the resize.

Thanks, that's a useful distinction. I agree Virtualize doesn't promise that an exact anchor will survive an arbitrary container resize. But after rerunning the exact current head, 944cbbd0808c62096fac2136882b926c548e214b, I don't think that's what this repro is showing.

The list initially puts item 1950 at the top for InitialItemIndex=1990, but its scroll height is already only 58,790px instead of the expected 100,000px. On the first 2500px -> 2000px resize, the first visible item moves to 1362 and the scroll height changes to 83,175px. It stays there through three more smaller/larger resize cycles.

The resize is exposing state that was corrupted during initial alignment:

1. JS measures 25 rendered rows with a 1,250px separation.
2. A 62-row window commits before that asynchronous result is consumed.
3. .NET applies the old 1,250px measurement using the current 62-row count.
4. The estimated row size changes from 50px to about 20.16px, which changes the spacer geometry used by the next redistribution.

So I'm not asking for a new promise that the exact jump target always survives resize. I'm asking that geometry from an older rendered slice not recalibrate a newer slice. That mismatch affects the component's internal size model and future virtualization behavior.

I repeated the same candidate-independent browser assertion in detached worktrees. The frozen ab1e067c implementation was red in 3/3 runs, and a correction that carries a monotonic rendered-window version with alignment and both spacer measurements was green in 3/3 runs for the 1990 case, the 1950 control, and a variable-height control. I then ran the exact 944cbbd0 head and it still fails the same assertion. I also had MAI, Claude Sonnet, and GPT Terra independently challenge whether this needed correction. All three concluded that it did after separating the GitHub head from the uncommitted candidate.

I agree the QuickGrid CI failure should be handled as a separate flake investigation. I'm not relying on that failure for this request.

I see this merged while I was finishing the current-head validation, and the release/11.0-rc1 backport has started. Could we take this result into account for the backport and decide whether to address it there or track it as an immediate follow-up?