Media: Add a checkbox to toggle infinite scrolling in the media modal

[itzmekhokan]

Adds a point-of-use control for infinite scrolling in the attachments browser, as a follow-up to #65564.

What the problem was:

• Infinite scrolling is enabled by default as of [62632], but the only way to change it is the "Infinite Scrolling" option on the user profile screen. Users who need the "Load more" button for accessibility, or who want to avoid loading a large library, have to leave the modal, change their profile, and come back.

What the fix does:

• Renders an "Infinite scrolling" checkbox before the list of media items, in both the media modal and the Media Library grid view, that turns infinite scrolling on and off immediately.
• Saves the change as the user's preference, so it persists beyond the current view. A new save-media-infinite-scrolling AJAX action writes the same infinite_scrolling personal option as the profile screen, and the two stay in sync in both directions.
• Confirms the change next to the checkbox and sends the same message to wp.a11y.speak(), because the controls that change are at the end of the list and usually out of view.
• Unchecking it reveals the "Load more" button and the item count and stops the scroll handler from requesting more attachments. Checking it hides them and resumes loading on scroll.
• Keeps the screen reader search-results message in sync with the active mode.

Approach and why:

• The checkbox is only rendered when saving the personal option takes effect. wp_enqueue_media() passes a new canToggleInfiniteScrolling setting, which is false when a media_library_infinite_scrolling filter callback overrides the option, or when there is no user to save it for. Announcing "Preference saved" for a value a filter overrides on the next page load would be misleading, so no control is offered in that case. This is deliberately blunt: any callback on the filter hides the control, even one that only applies conditionally.
• The media_library_infinite_scrolling filter and the profile option still determine the initial state, and their documented precedence is unchanged.
• infiniteScrolling moves from a module-level constant to per-instance state on AttachmentsBrowser, and is passed down to the Attachments view rather than read from the global a second time.
• The scroll handler is now always bound and bails when infinite scrolling is off, so it is live if the user turns scrolling on mid-session.
• To make room for a control before the list, .attachments-wrapper is now the positioned, scrolling region in both modes rather than only when the "Load more" button is present. This reuses the offsets that already applied to the wrapper at every breakpoint, so no per-breakpoint pixel values change.

Trac ticket: https://core.trac.wordpress.org/ticket/65775

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Ticket analysis, tests and generate PR. All changes were reviewed and validated by me.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props khokansardar, joedolson.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[joedolson]

This works well within a limited scope, but I think it needs to save the user's preference, rather than just persisting for the duration of the modal. Along with that, notices that inform the user of the preference toggle would be needed.

I pushed a minor visual improvement to fix alignments.

[joedolson]

I think that this label should just be "Infinite scrolling"; the checked status conveys whether it's enabled or not.

[joedolson]

I think it may be helpful to include some kind of visual affordance that confirms that something has happened, since all the control changes happen out of the viewport.

I also think that the control needs to save this preference for the user, so one possibility would be a notice that appears/is spoken saying "Infinite scrolling preference saved"

[itzmekhokan]

Thanks for the review — all three points are addressed in c763743.

• The label is now just "Infinite scrolling".
• The checkbox saves the preference. A new save-media-infinite-scrolling AJAX action writes the same infinite_scrolling personal option as the profile screen, so the control and the profile screen stay in sync in both directions.
• Changing it shows a confirmation next to the checkbox and sends the same message to wp.a11y.speak(): "Infinite scrolling disabled. Load more button displayed. Preference saved." and "Infinite scrolling enabled. Preference saved."

One decision worth your input. Since the control saves the personal option, wp_enqueue_media() now passes a canToggleInfiniteScrolling setting, and the checkbox is not rendered when a media_library_infinite_scrolling callback overrides that option — otherwise it would announce "Preference saved" for a value the filter resets on the next page load. That is deliberately blunt: any callback on the filter hides the control, even one that only applies conditionally. If you would rather keep the control visible and suppress only the notice in that case, I am happy to change it.