Block editor changing HTML entities within Shortcode block shortcode attribute values after reload

[MichelleBlanchette]

Description

HTML entities within shortcode attributes are modified by the block editor after reloading.

If the user does not make changes to the content, I believe the block editor should not modify that content. Furthermore, the content is correctly saved if the user manually replaces the encoded entities back to their original form.

This behavior seems to demonstrate that literal entities are acceptable in storage from the block editor and retrieval outside of the block editor. There seems to be a disconnect in entity encoding when content is loaded back into the block editor and then saved again.

Furthermore, HTML entities like <> within shortcode attributes cause the This block contains unexpected or invalid content. [ Attempt Block Recovery ] notice on the shortcode block.

Step-by-step reproduction instructions

1. Insert a Shortcode block
2. Enter a shortcode with an attribute whose value contains an ampersand &
3. Click "Update" in the block editor to save the post content
4. In PHP, error_log() the shortcode attribute's value and notice it correctly contains &
5. Refresh the webpage to reload the block editor
6. Notice that the & in the shortcode attribute is now displayed as &
7. Make no changes to the shortcode and click "Update" to again save the post content
8. In PHP, error_log() the shortcode attribute's value and notice it now contains &

Example shortcode

[my_shortcode_test text="Website & Development"]

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress version 6.2
• Tested with themes Twenty Twenty-Two (v1.4, latest) and Twenty Twenty-Three (v1.1, latest)

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 (not using the Gutenberg plugin, simply WordPress 6.2 with no active plugins)

[ndiego]

I was able to replicate the issues noted here. In doing a bit of digging, I believe this might be somewhat related to an issue that has been around for quite some time, see: https://core.trac.wordpress.org/ticket/45387