VideoPress: prevent false dirty state in Site Editor for legacy blocks

[shsajalchowdhury]

What

Fixes #48633

Why

When the Site Editor loads a template containing legacy wp:video blocks with VideoPress attributes (guid, videoPressClassNames), the editor persistently shows "Review 1 change" on every reload — even after saving. The dirty state is caused entirely client-side with no actual content change.

Root Cause

In componentDidUpdate, the VideoPress edit component unconditionally calls setAttributes( { videoPressClassNames: sandboxClassnames } ) whenever a preview is available. Even when the computed value is byte-for-byte identical to the existing attribute, the setAttributes dispatch marks the block (and by extension the template entity) as dirty.

How

Added a strict equality check: only call setAttributes when sandboxClassnames differs from the current attributes.videoPressClassNames value. This prevents the unnecessary dispatch that flags the entity as dirty.

Testing Instructions

1. Open the Site Editor on a site with Jetpack/VideoPress active
2. Edit a template via Code Editor and insert a legacy VideoPress block:

<!-- wp:video {"id":1,"guid":"239t8ryY","videoPressClassNames":"wp-block-embed is-type-video is-provider-videopress"} -->
<figure class="wp-block-video wp-block-embed is-type-video is-provider-videopress"><div class="wp-block-embed__wrapper">
https://videopress.com/v/239t8ryY?resizeToParent=true&amp;cover=true&amp;preloadContent=metadata&amp;useAverageColor=true
</div></figure>
<!-- /wp:video -->

3. Save the template
4. Reload the Site Editor
5. Before: "Review 1 change" appears immediately
6. After: No unsaved changes indicator

Changelog

VideoPress: prevent persistent "Review 1 change" in the Site Editor caused by unnecessary setAttributes calls when the videoPressClassNames value has not changed.

Does this pull request change what data or activity we track or use?

No. This change only adds a strict equality check before calling setAttributes — no data collection or tracking changes.

Testing instructions

1. Open the Site Editor on a site with Jetpack/VideoPress active
2. Edit a template via Code Editor and insert a legacy VideoPress block:
   <!-- wp:video {"id":1,"guid":"239t8ryY","videoPressClassNames":"wp-block-embed is-type-video is-provider-videopress"} --><figure class="wp-block-video wp-block-embed is-type-video is-provider-videopress"><div class="wp-block-embed__wrapper">https://videopress.com/v/239t8ryY?resizeToParent=true&cover=true&preloadContent=metadata&useAverageColor=true</div></figure><!-- /wp:video -->
3. Save the template
4. Reload the Site Editor
5. Before: The "Review 1 change" badge appears immediately
6. After: No unsaved changes indicator is shown

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

---

Jetpack plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jeherve]

Thank you for your contribution.

We'll need to fix the changelog format before we can merge this.

[obenland]

Thanks @shsajalchowdhury! It looks like this fixes it for the site editor, but the post editor still shows it dirty. I believe the videoPressTracks attribute being set there might be the culprit. Would you want to look at that, too?

[shsajalchowdhury]

Hi @jeherve, thanks for the review! The changelog type was already corrected from fixed to bugfix in a follow-up commit (b53dcaf). I've rebased on the latest trunk and force-pushed to trigger a fresh CI run. The code change itself is minimal — just a guard to only call setAttributes when sandboxClassnames differs from the current videoPressClassNames attribute value, preventing the unnecessary dirty state. Let me know if anything else needs adjusting!