[Blazor] Re-derive Virtualize at-bottom state when the anchor mode changes

[lewing]

Fixes the flake that #68731 quarantined, and re-enables the test.

Problem

VirtualizationTest.QuickGrid_AnchorMode_End_PrependAtTop_ViewportStaysStable failed 3 times in 30 days on main, always as ServerVirtualizationTest on the Mono E2E leg with useItemsProvider: True:

Scroll assertion failed: expected QuickGrid should start at the top,
but scrollTop=54778, scrollHeight=55078, clientHeight=300, maxScrollTop=54778

scrollTop == maxScrollTop, with byte-identical numbers across all three failures — the grid is pinned to the bottom of the list at a point where the test has not scrolled at all.

Root cause

isViewportAtBottom() treats a container that is not yet scrollable as being at the bottom:

const isViewportAtBottom = (): boolean =>
  scrollElement.scrollHeight <= scrollElement.clientHeight
  || Math.abs(scrollElement.scrollTop + scrollElement.clientHeight - scrollElement.scrollHeight) < 2;

bottomTracking.wasAtBottomLastRender is written from that predicate on every render, and outside of clearBottomFollow it is only reset by a user scroll. This test never scrolls — scrollTop stays 0 from mount until the assertion.

So an empty first render, or an async ItemsProvider round trip that briefly leaves the container shorter than its viewport, latches wasAtBottomLastRender = true and it stays latched. setAnchorMode then refreshed following and reached but left that stale flag alone:

setAnchorMode: (mode) => { anchorMode = mode; bottomTracking.following = (mode & 2) !== 0; bottomTracking.reached = isViewportAtBottom(); },

Selecting End mode therefore satisfied the re-pin guard in refreshObservedElements on the next render:

if ((anchorModeIs.end || bottomTracking.following) && (bottomTracking.wasAtBottomLastRender || bottomTracking.reached)) {
  scrollElement.scrollTop = scrollElement.scrollHeight;

It is intermittent because it depends on a render landing while the container is not scrollable. Interactive Server with a delayed provider widens that window, which matches the observed parameterization exactly.

Introduced by #67639 (bf41edc66b, Jul 20), which added the bottomTracking state machine and the wasAtBottomLastRender term in the guard. First failure Jul 30.

Fix

Re-derive all three flags from the live viewport when the anchor mode changes, mirroring what the user-scroll path already does. This also matches the existing reasoning in restoreAnchorForShift — "Don't rely on the cached wasAtBottomLastRender — it may be stale" — which setAnchorMode was not honoring.

Also removes the [QuarantinedTest] attribute added by #68731, since the underlying cause is fixed here.

Testing

Virtualize.test.ts was a 13-line export smoke test, so none of this state machine was covered. Added VirtualizeEndAnchorLatch.test.ts, which drives init / refreshObservers / setAnchorMode against stubbed observers and a DOM whose geometry can model "provider in flight" versus "data loaded":

• switching into End mode at the top does not jump to the bottom after a transient short list — fails without the fix with Received: 55078. The browser clamps that to 55078 - 300 = 54778, reproducing the CI value exactly. Passes with the fix.
• End mode still follows appends once the viewport has actually reached the bottom — passes with and without the fix, so the first test is not vacuous and Improve AnchorMode tests #67639's intended End-mode behavior is still exercised.

Full Web.JS jest suite: 208 passing, 0 failing. The 5 failing suites are pre-existing Cannot find module '@microsoft/signalr' resolution errors, identical with and without this change. eslint on Virtualize.ts goes from 40 to 38 reported problems — no new ones.

E2E confirmation depends on CI here, since the failure needs the Interactive Server + delayed-provider timing window.

Notes for reviewers

• Reject stale Blazor Virtualize viewport measurements #68691 also edits Virtualize.ts substantially. This change is confined to setAnchorMode, so it should rebase cleanly either way.
• This is a different defect from the InitialItemIndex near-end failure (Quarantine Microsoft.AspNetCore.Components.E2ETest.Tests.VirtualizationTest.QuickGrid_InitialIndex_TallContainer_NearEnd_FillsVi [Content truncated due to length] #68724). That one is still open: [Blazor] Keep Virtualize spacer callbacks programmatic while an alignment is pending #68709 only reduced its failure rate to 2/4 and was closed in favour of Reject stale Blazor Virtualize viewport measurements #68691.

Unrelated: the Aug 23 quarantine batch looks misattributed

The five quarantine PRs from Aug 23 cite a "most recent failing build" each. For three of them, that build's complete test-result set does not contain a failure of the test being quarantined:

• [test-quarantine] Quarantine QuickGrid_AnchorMode_NearTop_AppendKeepsViewportStable #68727 cites build 1562788, whose only E2E failures were QuickGrid_InitialIndex_TallContainer_NearEnd_FillsViewportWithoutUserScroll and ScrollToItem_UserScrollDuringProviderFetch_UserScrollWins.
• [test-quarantine] Quarantine AnchorMode_Start_LargePrependAtTop_StillShowsNewItems #68729 cites build 1550927, whose only Virtualization failure was AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage — in the Quarantine run, for a test already quarantined under Quarantine ServerVirtualizationTest.AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage flaky test #66970.
• [test-quarantine] Quarantine QuickGrid_AnchorMode_End_PrependAtTop_ViewportStaysStable #68731 (this PR's test) cites build 1551062, whose only Virtualization failure was QuickGrid_AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage.

The pattern fits resolving the stack-trace line number against current main rather than using the fully-qualified test name that is already in the trace, so a real failure gets attributed to whichever test now occupies that line:

• Build 1550927 (commit 8a3632c7), stack line 4290 → AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage. Line 4290 in today's main is inside AnchorMode_Start_LargePrependAtTop_StillShowsNewItems → filed as [test-quarantine] Quarantine AnchorMode_Start_LargePrependAtTop_StillShowsNewItems #68729.
• Build 1551062 (commit 9d6f69ad), stack line 2346 → QuickGrid_AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage. Line 2346 today is inside this PR's test → filed as [test-quarantine] Quarantine QuickGrid_AnchorMode_End_PrependAtTop_ViewportStaysStable #68731.

Observed failure counts versus what the PRs claimed:

Merged PR	Quarantined test	Claimed	Observed
#68727	QuickGrid_AnchorMode_NearTop_AppendKeepsViewportStable	4	1
#68729	AnchorMode_Start_LargePrependAtTop_StillShowsNewItems	3	0

Scope of that check, so the limits are explicit: every aspnetcore-components-e2e build — the only pipeline that runs these, since aspnetcore-ci Helix legs contain no Components.E2ETest results — across all branches including 201 PR builds, counting every non-passing outcome, over the 392 builds from Jul 27 to Aug 24. AzDO has purged def-87 builds older than Jul 27, so roughly the first two days of the PRs' 30-day window are no longer observable.

The single NearTop failure was build 1562094 on PR #68664, an unrelated Kestrel DirectTLS change: Assert.NotNull() Failure: Value is null in GetItemPositionInContainer — a different signature from the scroll-position failures, and not the defect fixed here.

Two follow-ons regardless: already-quarantined failures should not seed new quarantines, and the batch missed a genuinely un-quarantined flake, QuickGrid_AnchorMode_End_AppendAfterLeavingBottom_DoesNotReengage (2 live failures), which shares the async-provider/Server/Mono signature and may share this PR's root cause.

[Copilot]

Pull request overview

This PR fixes a Blazor Virtualize/QuickGrid flake where switching into AnchorMode.End could incorrectly “pin” the viewport to the bottom due to a stale cached “at-bottom” flag captured during a transient non-scrollable render (e.g., async ItemsProvider in-flight).

Changes:

• Re-derives bottomTracking at-bottom state (reached and wasAtBottomLastRender) from the live viewport when setAnchorMode is invoked.
• Adds a focused Jest regression test that simulates the transient “short list” window and validates that switching into End mode while at top does not jump to bottom.
• Adds an additional Jest test asserting End-mode follow behavior on append.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Components/Web.JS/src/Virtualize.ts	Recomputes all at-bottom tracking flags when anchor mode changes to prevent stale-state re-pinning.
src/Components/Web.JS/test/VirtualizeEndAnchorLatch.test.ts	Adds regression coverage for the End-mode “at-bottom latch” scenario and for End-mode follow-on-append behavior.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.