DataViews: Fix infinite-scroll jump on async page loads

[arthur791004]

What?

Fixes the DataViews infinite-scroll (List layout) list jumping while pages load asynchronously. Adds a realistic network-backed story to reproduce it.

Why?

For any consumer that loads pages over the network, scrolling down to load more made the list jump. There are two independent causes:

1. Scroll-anchor restoration discarded the user's scrolling. The anchor is captured when the window advances but only restored after the load finishes. If the user keeps scrolling in that gap, the restoration snapped the list back to the capture-time position — undoing that scrolling (a ~hundreds-of-pixels jump).
2. The footer resized the scroll container mid-load. DataViewsFooter renders only while "refreshing" (isLoading). For infinite scroll there's no pagination, so it had nothing to show, yet it mounted on every load — a sticky, flex-shrink: 0 bar that shrank the scroll viewport by its height and reflowed the list.

The existing synchronous story never hit either: it resolves data immediately and never sets a loading state.

How?

• Anchor restoration: also store scrollTop at capture and add back the scroll delta since then, so the restoration compensates only the content-driven shift, not the user's own scrolling. When the user doesn't scroll during a load, the added term is zero — behaviour is unchanged in that case.
• Footer: for infinite scroll, don't render the footer when there are no bulk actions to show (the in-list spinner already indicates loading). This keeps the scroll container a constant size across loads.
• In-list spinner: reserve its space while more items remain (hasMoreItems) so it doesn't change height as loading toggles, and drop it once everything is loaded.

Considerations

Scroll anchoring depends on real layout/scroll, which jsdom does not simulate, so this is verified through the Storybook story in a real browser rather than a unit test. Both causes were isolated by reverting each fix independently and confirming the jump returns.

Row unloading (useData's IntersectionObserver buffer) is intentionally not wired into the List layout here: unloading shifts the array-relative aria-posinset the anchor relies on, which reintroduces the snap-back. Bounding the DOM for very large lists is a separate concern.

Testing Instructions

1. npm run storybook:dev
2. Open DataViews → DataViews → Async Infinite Scroll (each page loads with simulated latency).
3. Scroll down through several pages, and keep scrolling while a page is loading.
4. Expected: the list does not jump as each page settles.
5. To see the original bug, check out either packages/dataviews/src/hooks/use-infinite-scroll.ts or packages/dataviews/src/components/dataviews-footer/index.tsx from trunk and repeat.

Testing Instructions for Keyboard

Not a markup/interaction change. The list can still be scrolled with the keyboard (focus a row, then Page Down / arrow keys); the same behaviour applies.

Screenshots or screencast

Before	After
List jumps as each async page settles	Scroll position stays put

Use of AI Tools

This change was authored with the assistance of AI tooling (Claude Code), and verified in Storybook (the two causes were isolated by independent A/B reverts).

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: arthur791004 <arthur791004@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[tellthemachines]

Thanks for the PR!

For another place to do real-life testing of this change, I just put up #79661 which adds infinite scroll to the experimental media upload modal for testing purposes (not meant to be merged)

[tellthemachines]

I just realised something: after #74378, the intersection observer logic that allows unloading items from the top when the dataset gets too big was never added to the list layout, or to the table or activity ones. It still only works on picker-table, picker-grid and grid.

While these changes are working well with the list layout as it stands, the intention was always to add the intersection observer to all the layout types; the problem is that the unloading affects scrollTop and might change how well this fix is working. Given we're already making infinite scroll-related changes to list here, I think it might be worth adding the intersection observer and adjusting the fix accordingly.

I'm playing with that locally now, so might put up a PR pointing to this one and we'll see how it works!

[arthur791004]

the intersection observer logic that allows unloading items from the top when the dataset gets too big was never added to the list layout

I tried to bring this feature to the list view, but the scroll position was still behaving strangely. I'm not sure if there's a quick way to fix it, so I decided to skip it for now.

[tellthemachines]

This is generally testing well for me; my main question is about the logic behind hiding the footer. (Also, what happens when we do have bulk actions and need to show the footer? Will the list be jumpy then?)

I went down a bit of a rabbit hole with the intersection observer thing, and ended up with #79728. It still needs human review on my side but it does seem to work well in testing. If you want to give it a test run I'd appreciate feedback on how well it works to fix the list jumpiness issues!

I think we can still get this PR in first though, and then follow up with the intersection observer work so we don't hold up fixing the existing bug.

[tellthemachines]

mounting it on each load resized the scroll container and jumped the list

Are we sure about this? The footer should stick to the bottom of the screen and it's not part of the layout container, so I wouldn't expect any resizing 🤔

[arthur791004]

If you force the footer to always be visible, scroll to the bottom, and toggle display: none in DevTools, you will see a layout shift like the one below:

dataviews-footer-jump.mov

[github-actions]

Size Change: +310 B (0%)

Total Size: 7.63 MB

📦 View Changed

Filename	Size	Change
build/modules/content-types/index.min.js	160 kB	+37 B (+0.02%)
build/scripts/edit-site/index.min.js	298 kB	+74 B (+0.02%)
build/scripts/editor/index.min.js	490 kB	+22 B (0%)
build/scripts/media-utils/index.min.js	115 kB	+49 B (+0.04%)
build/styles/edit-site/style-rtl.css	21.6 kB	+18 B (+0.08%)
build/styles/edit-site/style-rtl.min.css	17.8 kB	+15 B (+0.08%)
build/styles/edit-site/style.css	21.6 kB	+18 B (+0.08%)
build/styles/edit-site/style.min.css	17.8 kB	+15 B (+0.08%)
build/styles/editor/style-rtl.css	31 kB	+17 B (+0.05%)
build/styles/editor/style-rtl.min.css	26.3 kB	+14 B (+0.05%)
build/styles/editor/style.css	31 kB	+17 B (+0.05%)
build/styles/editor/style.min.css	26.2 kB	+14 B (+0.05%)

_{compressed-size-action}

[arthur791004]

my main question is about the logic behind hiding the footer. (Also, what happens when we do have bulk actions and need to show the footer? Will the list be jumpy then?)

I pushed the changes in 989d486 to update the logic for showing/hiding the footer.

My thinking is that the footer should always be visible if there are multiple pages (totalPages > 1) or if any bulk actions are available. Does it make sense?

I think we can still get this PR in first though, and then follow up with the intersection observer work so we don't hold up fixing the existing bug.

Sounds good 👍

[github-actions]

Flaky tests detected in 989d486.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/28572812045
📝 Reported issues:

• [Flaky Test] activate block theme when live previewing in edit mode #77712 in /test/e2e/specs/site-editor/activate-theme.spec.js

[tellthemachines]

Thanks for iterating, this LGTM! I tested with all the other layouts containing infinite scroll and everything is still working as expected.

[arthur791004]

Thanks so much for the thorough testing and the review!