Media: Client-side uploads for media-new.php and a guard for in-flight uploads

[adamsilverstein]

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

Note

Stacked on #12585 (Trac #65661): the branch builds on add/media-library-client-side-uploads, so only the last 3 commits are new here.

What

Two follow-ups that #12585 explicitly left out of scope:

1. The "Add New Media File" screen (media-new.php). It uses a separate uploader path: plupload-handlers creates a raw plupload.Uploader (wp.Uploader never loads there) posting to async-upload.php with all image processing server-side. It was the last remaining admin upload surface without client-side pipeline integration.
2. A beforeunload guard while pipeline uploads are in flight. Interrupting a pipeline upload is worse than interrupting a classic one: classic uploads complete server-side once the bytes arrive, but an interrupted pipeline upload loses browser-generated thumbnails that were not sideloaded yet and leaves the attachment unfinalized.

How

Commit 1 - beforeunload guard for the grid. media-library-upload.js triggers the browser's leave confirmation while its progress map is non-empty (models stay there from interception until success or error). Scoped to the pipeline; classic uploads behave exactly as before.

Commit 2 - media-new.php pipeline routing. A new wp_set_up_media_new_cross_origin_isolation() on load-media-new.php extends core's Document-Isolation-Policy output buffer to the screen, gated on client-side processing being enabled and upload_files (the screen itself already requires it; no mode gating applies). A new media-new-upload admin script binds a higher-priority FilesAdded handler on the plupload-handlers uploader instance and routes files through the @wordpress/upload-media store, sharing settings with the grid integration via wp_get_media_library_upload_settings().

The screen's existing UI helpers are reused rather than replicated: fileQueued() builds the progress item, uploadSuccess() renders the finished attachment row through the existing async-upload.php?fetch=3 markup endpoint, itemAjaxError() surfaces per-file errors, and uploadComplete() runs when the queue drains - so the screen looks and behaves unchanged. Store progress is mirrored onto the screen's progress bars, and the same beforeunload guard applies. When the browser is not cross-origin isolated or lacks client-side support, the script no-ops and the classic plupload flow (and the ?browser-uploader HTML fallback form) keep working unchanged - degradation, never data loss.

The mediaSideload/mediaFinalize apiFetch wrappers are intentionally duplicated from the grid script rather than extracted into a shared handle: they are thin, and the two screens share no other loadable script (the grid script requires wp.Uploader/media-views, which media-new.php never loads).

Commit 3 - E2E coverage. New spec asserting the DIP header on media-new.php, the happy-path upload (create + sideload + finalize via REST, no file upload through async-upload.php; the fetch=3 markup POST is expected and excluded), and the disallowed-file-type error path. As in #12585, Playwright's Chromium lacks Document-Isolation-Policy support, so upload assertions skip when the context is not isolated; the header assertion always runs.

One deliberate scope choice: the built-in FilesAdded handler blocks WebP/AVIF (and warns for HEIC) when the server cannot edit them; the pipeline handler bypasses those checks because conversion happens client-side - the same behavior the grid integration has.

Testing

• 9 new PHPUnit tests (wpMediaNewCrossOriginIsolation.php, wpEnqueueMediaNewUpload.php) pass locally, as do the two suites from Media: Enable client-side media uploads in the Media Library grid #12585.
• PHPCS: no new issues on the touched files. JSHint passes on the new and modified scripts.
• Manual flow to verify (Chrome 137+, secure origin): upload on Media > Add New Media File and observe REST create/sideload/finalize in DevTools with no upload POST to async-upload.php; the progress item resolves to the normal row with Edit and Copy URL links; closing the tab mid-upload prompts for confirmation; Firefox/Safari and ?browser-uploader keep the classic path.

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

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.