Uploads from the editor's media library modal still go through the server #82409

I ran into this while testing HEIC uploads: the same file succeeds when dropped on an Image block and fails when dropped on the Insert image->from Media Library option,

Here is a failure trying to upload an AVIF which is supported under client side media:

Screencast below.

Claude wrote this up after going through the screencast and the code:

Description

Dropping an image directly on an Image block runs it through the client-side media pipeline: a HEIC file is converted to JPEG in the browser and the upload succeeds. Opening the media modal from the same block (the "Media Library" button, then either the "Upload files" or the "Media Library" tab of the "Select or Upload Media" dialog) and dropping the same file there goes through wp.Uploader / plupload to async-upload.php, and the server rejects it with "The server cannot process HEIC images. Convert it to JPEG before uploading."

The client-side pipeline is wired in through the block editor's mediaUpload setting in https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/provider/index.jsx, which only covers uploads the editor itself starts (block drops, the Upload button, the inserter). The modal is Backbone wp.media, and its uploader is core's wp.Uploader in https://github.com/WordPress/wordpress-develop/blob/trunk/src/js/_enqueues/vendor/plupload/wp-plupload.js, which nothing intercepts. So it posts the original bytes server-side even though the page is already cross-origin isolated and @wordpress/upload-media is loaded and configured.

Beyond HEIC, files dropped on the modal skip everything the pipeline does: browser-generated sub-sizes, the big-image threshold, animated GIF handling, and so on. Users are unlikely to notice which surface they used, so the two behaving differently reads as flaky.

Step-by-step reproduction instructions

1. On a site with client-side media processing enabled (WordPress 7.1+ or trunk), open a post in the editor in a browser where the pipeline runs (Chrome 137+, or Firefox with COEP/COOP headers).
2. Add an Image block and drop a HEIC file (any iPhone photo) on it. It converts and uploads.
3. Add another Image block, click "Media Library", and drop the same HEIC file on the modal.

Expected behaviour

The modal upload runs through the same client-side pipeline as the block drop, so the HEIC is converted in the browser and the upload succeeds.

Current behaviour

The modal posts the raw file to async-upload.php and shows "The server cannot process HEIC images. Convert it to JPEG before uploading." in the modal's error sidebar.

Possible approach

On editor screens where the pipeline is active, bind a higher-priority FilesAdded handler on wp.Uploader instances (the modal's included) that routes the files through the @wordpress/upload-media store and mirrors plupload's placeholder attachments, progress, and wp.Uploader.errors so the modal UI works unchanged. That is what WordPress/wordpress-develop#12585 does for the Media Library grid and the Add New Media File screen outside the editor, and the same wrapper could cover the modal. Whether this belongs in core (wp-plupload.js detecting an active pipeline itself) or in Gutenberg is an open question.

Related: WordPress/wordpress-develop#12585 (core PR for the Media Library screens), adamsilverstein/client-side-media-everywhere#49 (plugin version of the same)

The modal should use the same client side media processing we use elsewhere as long as it is available.

Screencast

cc: @swissspidy @andrewserong

AI Use

Description written with 🤖 Claude Code.