Add option to toggle infinite scroll in the media modal

[joedolson]

With the conversion back to supporting infinite scroll by default, it is crucial for accessibility that users be able to change that setting at the point of use.

For some users, it may also be a use case scenario: in most cases, you may only need to access a recently upload item, and only want to turn this on if you know you're looking for an image that's considerably further back. In those cases, being able to toggle this on the fly can significantly reduce the performance demand in your default usage.

The option should be a checkbox, placed in the DOM before the list of media items.

[joedolson]

See related: #65564, #40330, #50105

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 a 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.
• 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 reflects the value resolved by wp_enqueue_media() and overrides it for the current view only, so the media_library_infinite_scrolling filter and the user 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.

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

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

Tested this out and the experience feels a bit rough. It doesn't automatically update when you change your preference. The alignment of the text for the option is also off, both for the initial "Infinite scrolling" and what I think is the description text when you select an option (it seems like this still isn't fixed?)

The double infinite scrolling text feels repetitive too. Let's get some @WordPress/gutenberg-design help here in terms of phrasing and placement! We want it to fit in well with other approaches WordPress takes.

@annezazu In my testing, I *thought* it wasn't switching modes when I checked it, but it actually did; it was just slightly difficult to tell in my test environment, for two reasons: there wasn't a sharp difference between the number loaded in infinite scroll and the total, and because if you've already scrolled to the end, not much actually changes - there's nothing more to load. Can you double check that? (My testing was on the previous iteration of the PR, so it is possible that it's regressed since I checked.)

I tested with 87 photos on a site and if I turned it off, the load more never appeared. I had to navigate away and back for it to show.

I almost wonder if a better option is to have a dismissible notice that tells folks there’s an option available to control this in your profile options rather than permanently placing this here. Again, I want to hear from more designers!

To be perfectly honest, I feel this toggle is too conspicuous and might unnecessarily complicate things. Furthermore, I question whether the average user is familiar with the term "infinite scrolling." I'm also hesitant to make such a significant code change right before RC1.

My proposal is to simply revert the default behavior of infinite scrolling to "disabled" without adding a toggle, while still maintaining the user option. This allows users to maintain the previous default behavior while offering an option for users who prefer infinite scrolling.

I also wonder if this setting needs to be on the fly. Dynamically switching infinite scroll is a feature that hasn't been around before, and as mentioned, it's hard to tell if dynamically switching infinite scroll is actually working unless there are a lot of images, and it seems like it would only confuse users.

That’s against what @m has explicitly asked for (on by default with the option to disable). This is a project leadership call that’s already been made.

[tyxla]

@joen @fcoveram: could I ask for your opinions about the feasibility of the proposed checkbox from a design perspective? Any suggestions or thoughts to share?

Agree with @t-hamano about the settings location and the familiarity with the term. To me, this belongs to a system preference, similar to changing from light to dark mode and increasing UI contrast. Therefore, I would expect this in the wp-admin settings.

Aki's example shows it in General, but it makes more sense to me in Media just before the "Image sizes" heading. Also, if the setting only impacts the modal view and the grid layout can not be modified, then the copy could be more explicit:

Infinite scroll: [ ] Enable infinite scrolling in modal

The above is a suggestion in addition to showing it on by default, as Anne said.

---

I might be missing some context here, but the latest changes use DataViewsPicker and the modern UI, but I see the previous in this PR.

If the setting is agreed to be displayed on this screen, and the use of DataViewsPicker remains, I would place it in the View options menu.

Thanks for the attention to detail.

In balancing leadership direction as far as defaults, with preferences that enable options to accommodate everyone, immediately coming to mind is our desire for a welcome-modal that through an out-of-box experience can let everyone quickly set their personal preferences. ​[Jay Koster explores this in-depth](​https://make.wordpress.org/design/2022/08/04/design-exploration-encourage-editor-configuration-during-on-boarding/), noting that not one size fits all.

That's a long term consideration. Important to know about to contextualise what we do, but not a near-term fix.

A user-level opt-out already exists. My understanding is that this opt-out is suggested as being not-discoverable-enough. The way to improve this discoverability is through slow and sustained iteration of the IA to ensure that the same things live in the same places. Users > Profile is perhaps a confusing place for finding things like your colour schemes. But Fran with his mention of Dark Mode alludes to a solution: with the admin-bar everywhere, I would expect a much more prominent and improved CTA for configuring user preferences in that dropdown, clearer than simply "Edit Profile":

It's not in a great place at the moment, with "admin" and "Edit Profile" being two lines of text inside the same link. As a drop-down menu, I'd expect "Admin" being text, "Edit Profile" and "Log Out" to be menu items. I'd even suggest that "Edit profile" item could be a button with a clearer label, and perhaps help text: "Customise your profile, preferred colour scheme, and interaction settings." That's an iterative design task, worth doing regardless of where we land.

---

For the approach outlined in this PR, let's be clear however what it is we're building: it's a per-view user preference.

Importantly, that has precedence:

• The incoming DataViewsPicker and media modal experiments (which also feature ​infinite scroll options, as well as [url DataViews]: both provide per-view options. Users might simply want to mix and match based on view: for Media, infinite scroll might be a more glanceable way to find what you're looking for, whereas for Pages you might prefer pagination with 20 items per page in a comfortable density.
• Posts, Pages, Comments feature a Screen Options tab, which similarly lets you configure items per page and density.

In both cases, per-view options make sense. The challenge here is that the present default media library has no view options: there's no "Screen Options", and there's no Appearance control like in DataViews on the other hand:

This omission feels like a compromise in the name of its modal variant, moreso than an intentional and considered design choice.

Because of that, and absent a simple way to introduce a screen options tab for Media, the solution would be to add a view-config button similar to what DataViews has: reuse the same pattern, and put the infinite scroll toggle inside that. Infinite scroll, items per page, view density: all are valid per-view controls, and none of them deserve the prominence of permanent visibility above the list of media.

Is it possible to move that toggle to the toolbar?

I might be missing some context here, but the latest changes use DataViewsPicker and the modern UI, but I see the previous in this PR.

The dataview-based media modal is still an experimental feature.

Is it possible to move that toggle to the toolbar?

From a purely personal opinion, but ultimately deferring to leads chiming in, this feels like a bandaid solution. The most direct pattern to follow is a cog button that opens a menu, with the toggle inside.

Thanks for the thoughtful response @jasmussen

I second you approach, and +1 to this

…The most direct pattern to follow is a cog button that opens a menu, with the toggle inside.

---

To @t-hamano

The dataview-based media modal is still an experimental feature.

You're right, my mistake. I confused it with the media edit in modal 🙃.

There are two key things in the recent threads that I think are key:

1) The user profile is a good place for user settings to live. However, the user profile labeling and context isn't well exposed, leading it to not appear like a natural place for users to go to manager their user preferences. While that's outside the scope of what should be targeted for 7.1, I think it would be an important change to look at for 7.2; it would make a lot of things more sensible.

2) Placing a tool for setting options in the media library does actually make some sense. The media library isn't currently designed for that, but I suggest it could live next to the media tabs or next to the close button, for ready discoverability.

[adrianduffell]

With the 7.1 RC 1 commit freeze a few hours away, let's keep this in the cycle and possibly aim for RC 2.

I'm unsure how to proceed with this PR.

Because of that, and absent a simple way to introduce a screen options tab for Media, the solution would be to add a view-config button similar to what DataViews has: reuse the same pattern, and put the infinite scroll toggle inside that. Infinite scroll, items per page, view density: all are valid per-view controls, and none of them deserve the prominence of permanent visibility above the list of media.

Should we perhaps try this approach once?

• Alternatives to #12795
• Trac ticket: https://core.trac.wordpress.org/ticket/65775

## Overview

WordPress core does not yet seem to have an API for rendering what are known as popovers. This PR instead attempts to render a settings dialog for the media library using the HTML native dialog element.

## Use of AI Tools

Note that this PR is a prototype. Almost all of the code in this PR was generated by Claude. If we find the approach taken in this PR to be reasonable, I would like to review all of the code.

## Screenshots

I believe that some implementation is necessary for the upcoming release of 7.1 RC3 next week. To move this forward, let's first discuss and agree on a general approach that seems reasonable from both design and accessibility perspectives.

One idea I had was to add a toggle button to display the settings for the media library as a dialog. I would appreciate your feedback.

​https://github.com/WordPress/wordpress-develop/pull/12932

Thanks for your efforts. The approach you took in 12932 is maybe not visually in the best place, but conceptually it uses mostly the same language as DataViews does, which is important from a "same things in the same places" perspective. So if it can build a consensus, I can support it on the path to more iteration in the future.

I pushed a few minor visual tweaks and changed the label configuration to avoid using an implicit label. Overall, I think this is very workable.

I noticed that the modal is not actually restricting focus, so that will need to be adjusted, but this is going in a direction that I think is viable.

I believe I've addressed all the issues I could think of. We should be ready for review now.

One idea I had was to add a toggle button to display the settings for the media library as a dialog. I would appreciate your feedback.

​https://github.com/WordPress/wordpress-develop/pull/12932

I'm ready to review this PR. Personally, I'd like to move this PR forward. I welcome your review.

Pushed two changes on narrower viewports - the button position below 782px and the button size between 782px and 900px.

I don’t think this is very discoverable or well connected to the media library. As Joe notes above, it feels more about search options. I’m not comfortable right now proceeding with this, especially with where we are in the release cycle too.

@annezazu Honestly, the positioning of the button is a relatively trivial part of this; relocating that is very doable. The more important part, in my opinion, is:

• Is a settings toggle a good idea? (In my opinion yes, this is an appropriate place for this.)
• Is the dialog functional, accessible, and clear? (Also in my opinion, yes.)

But I'm not convinced by the location; I think it was better when it wasn't directly inlined with the search field, however, and think it probably should be even earlier in the modal.

it feels more about search options

We could indicate that the button is an independent option by placing everything except the toggle button on the left side, but I believe this would require a significant CSS change. I believe the structure of the media toolbar needs a fundamental overhaul.

The button location shown in @t-hamano's message above looks good to me. The layout is similar to that in DataViews (Picker) and the media upload UX.

@jasmussen I just requested review from you here but saw @fcoveram's feedback late. Thank you both!

Happy to ship this as well! Thanks all.

We could indicate that the button is an independent option by placing everything except the toggle button on the left side, but I believe this would require a significant CSS change. I believe the structure of the media toolbar needs a fundamental overhaul.

To be honest, I'm hesitant to make major CSS changes around the media view and media toolbar right now because the CSS is overly complex 😅 While we might refactor the media-related UI with modern CSS in the future, I don't want to do that right before the final RC release. Let's find an acceptable compromise for the 7.1 release.

@tyxla Thanks for the review!

My main hesitation is timing rather than the code. We're at RC2, and this adds a new public JS API, a new AJAX endpoint, and runtime layout changes to one of the most-exercised screens in the admin, one that a lot of plugins hook into. The issues I highlight in review are in runtime the happy path, which makes me suspect there's more we haven't found yet.

I agree with this. While I understand the importance of improving accessibility, there is also a risk of causing problems by introducing new APIs.

This might go against ​the decision, but personally I propose punting this PR to 7.2. There is too little time to prepare.

cc @annezazu @joedolson

Could we get some broad manual testing before this lands? Toggling the setting mid-session in both grid mode and the modal, across browsers, with filters and search active, and with at least one plugin that customises the media views.

I tested the layout changes when the Media Library Assistant plugin, which extends the media toolbar, was enabled.

<details><summary>Before</summary>

</details>

<details><summary>After</summary>

</details>

Test in Playground

I tested PR #12932 for the first time, and I don't think it would be immediately obvious to users that they need to click the gear icon.

I think the “Enable infinite scrolling” checkbox could be placed somewhere more visible and intuitive, so users can discover the setting more easily.

[joedolson]

In light of the risks this significant change posts this late in the release cycle, and following discussion in the accessibility bug scrub, as well as comments by @wildworks and @tyxla regarding the complexity, we think that we have to push this to 7.2.

I'm going to move it to 7.2

I think we also need consider additional CSS changes to make the media modal's filter containers and search bar more reliable across viewports, as part of the problem here is in consistently positioning and placing the controls in the interface.

Coming here to say that I agree we need to punt this from the 7.1 release. I am just uncomfortable with these kinds of changes at this stage of the release process when we need utmost stability. I also think this is worthy of being considered for a point release for 7.1 and that's something we can pursue without waiting months until 7.2.

[joedolson]

Per @annezazu's comment in the PR, I'm milestoning this for 7.1.1.

[adrianduffell]

This was discussed in Friday’s bug scrub. It seems unlikely to be ready for 7.1.1, but could be included in a possible 7.1.2 release.

Next steps are to leave test/reviewer feedback on the PRs:

​https://github.com/WordPress/wordpress-develop/pull/12932
​https://github.com/WordPress/wordpress-develop/pull/12795