Save Button Disabled After Editing a Heading When “Table of Contents” Block is Present

[SainathPoojary]

Description

When a “Table of Contents” block is present in the post and changes are made to a heading block, the Save button remains disabled, even though changes have been made. However, making changes to any other block (other than the heading block) correctly enables the Save button.

This issue prevents users from saving their changes after modifying headings unless they interact with another block, which disrupts the workflow.

Step-by-step reproduction instructions

1. Create a new post or edit an existing one in the Gutenberg editor.
2. Add a “Table of Contents” block to the post.
3. Add a Heading blocks to the content.
4. Make a change to the Heading blocks (e.g., change the text).
5. Observe that the Save button remains disabled.
6. Make a change to any other block (e.g., a Paragraph block).
7. Observe that the Save button is now enabled.

Screenshots, screen recording, code snippet

• WordPress: 6.8-alpha-59467
• PHP: 8.2.26
• Server: Apache/2.4.62 (Debian)
• Database: mysqli (Server: 11.4.4-MariaDB-ubu2404 / Client: mysqlnd 8.2.26)
• Browser: Chrome 131.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins: Gutenberg 19.8.0-rc.1

Environment info

2024-12-04.20-03-58.mp4

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

[Infinite-Null]

Hi @SainathPoojary ,
Thank you for bringing this up I was successfully able to reproduce it.

Screencast

Screen.Recording.2024-12-04.at.8.37.31.PM.mov

I will work on it and try to find out why this issue occur

[Infinite-Null]

Hi @SainathPoojary,

I was able to identify the issue in the codebase here. After removing this line, the problem seems to be resolved.

During my research, I noticed that this line was introduced by @Mamaduka.

Hi @Mamaduka, would you please explain the purpose of the __unstableMarkNextChangeAsNotPersistent()? Do you think removing it would be an appropriate solution to the issue?

I’d be happy to proceed with a pull request based on your guidance.

Before Removing:

Screen.Recording.2024-12-05.at.11.02.40.PM.mov

After Removing:

Screen.Recording.2024-12-05.at.11.03.28.PM.mov

[Mamaduka]

This is closely related to #41031. Removal of __unstableMarkNextChangeAsNotPersistent will worsen the history bug; we can't just remove it.

The TOC block is still experimental, so this bug has low priority.

[Infinite-Null]

Thank you for your input @Mamaduka.