File block: Embedded PDF preview does not update on replacement in Chrome due to missing key on <object> element #83290

Description

Update: Further investigation confirms that @wordpress/upload-media does pass the server attachment to onChange, and the File block's attributes (id, href) do successfully update in state.

However, the embedded PDF preview in the editor canvas remains frozen on the original document in Chrome / Chromium browsers.

In packages/block-library/src/file/edit.jsx, the preview is rendered via:

<object
    className="wp-block-file__preview"
    data={ href }
    type="application/pdf"
    aria-label={ __( 'Embed of the selected PDF file.' ) }
/>

Because <object> lacks a React key prop (key={ href }), React updates the DOM attribute in-place (element.setAttribute('data', newHref)) without remounting the node. In Chromium browsers, the native PDF viewer (PDFium) does not reload or re-render when the data attribute on an existing <object> DOM node is modified dynamically.

Furthermore, when users replace a document using a file with the same filename (e.g. uploading a weekly newsletter named newsletter.pdf), WordPress derives the attachment title from the filename, so the block's text link title (fileName) also remains identical, making the block appear visually stuck on the original file.

When WordPress 7.1's Client-Side Media Processing feature is enabled (e.g., wp_is_client_side_media_processing_enabled() returns true), replacing an existing media item in any block that uses MediaReplaceFlow (e.g. core/file, core/image, core/cover, core/audio, core/video) via the toolbar option "Replace" → "Upload" fails to link the newly uploaded file to the block.

The server upload succeeds in the background and a new attachment is successfully created in the WordPress Media Library. However, the block in the editor permanently retains the previous attachment's id, url/href, and fileName. In the case of core/file, the embedded PDF preview continues to reference and render the original file.

Step-by-step reproduction instructions

1. Use an environment with WordPress 7.1+ and Client-Side Media Processing enabled (window.__clientSideMediaProcessing = true). Open the Block Editor in Chrome.
2. Insert a File block (core/file).
3. Upload a PDF file with distinct visual content (e.g. newsletter.pdf displaying "Issue 1"). Notice the block renders the preview.
4. Click on the File block to show the block toolbar.
5. Click Replace → Upload (or Replace → Open Media Library).
6. Select a replacement PDF file with different visual content (e.g. a new file displaying "Issue 2", whether with the same filename or a different filename).
7. Wait for the upload/selection to complete.
8. Observe: The File block does not update to the new attachment. The block attributes (id, href, fileName) still reference the original file, and In Chrome, the block attributes update in state and the DOM data attribute updates, but the embedded PDF preview continues to display the original document ("Issue 1").
9. Open the WordPress Media Library: observe that the new file was uploaded and exists as a new attachment in the database, but was never linked to the block. Choosing the new file from the Media Library also leaves the embedded PDF preview frozen on the original document.

Screenshots, screen recording, code snippet

Proposed fix in packages/block-library/src/file/edit.jsx:

- <object
+ <object
+     key={ href }
      className="wp-block-file__preview"
      data={ href }
      type="application/pdf"
      aria-label={ __( 'Embed of the selected PDF file.' ) }
  />

Environment info

• WordPress Version: 7.1.0 / 7.1.1 / 7.1.2
• Gutenberg Package: @wordpress/block-editor, @wordpress/block-library
• Browsers Tested: Chrome / Chromium-based browsers (Edge, Brave)
• Browser Engine: Chromium PDFium

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure