RTC: Save button does not reactivate in all windows following edits

[peterwilsoncc]

Description

When using RTC with multiple collaborators in the room, the save button only changes state for new content if when the content is changed by the current editor.

If another editor adds/removes content while the save button is disabled, the button will not be re-enabled.

Tested against WordPress-Develop without Gutenberg plugin being active.

Step-by-step reproduction instructions

1. Create a fresh install
2. Enable RTC
3. Open the Hello World post in two tabs
4. Observe that the save button is disabled in both tabs
5. In one tab edit the content
6. Observe that the save button activates -- do not click it
7. Switch to the other tab
8. Observe that the save button is disabled

Screenshots, screen recording, code snippet

Environment info

• WordPress: 7.0-beta5-61991-src
• PHP: 8.5.3
• Server: nginx/1.24.0
• Database: mysqli (Server: 8.0.44-0ubuntu0.24.04.2 / Client: mysqlnd 8.5.3)
• Browser: Firefox 148.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins:
  • _admin_bar_show_cache.php
  • _qm-mappings.php
• Plugins:
  • Query Monitor 3.20.3
  • Test Reports 1.2.1

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

[ingeniumed]

What I noticed is that the save button does become visible for the other collaborator but the timing isn't always consistent. It can be instantaneous, or it could take a few seconds to become visible.

Attempt 1

In this attempt, you can see that save button becomes visible instantly.

76656Bug.mp4

Attempt 2

In this attempt, you can see that the save button takes a few seconds to become visible.

76656Bug2.mp4

Given we hook into the EDIT_ENTITY_RECORD action, I console logged whenever it was fired for each collaborator while trying to replicate this bug. The timing depends on the action being fired with the updated content of the post. Until that's fired, the save button won't be made visible for the other collaborators.

Looking at the classic revisions UI, the timing lines up with autosaves. So when the autosave fires, the save button becomes visible for all collaborators as the changes were automatically saved.

This led me down a path to figure out why is the content not showing up as changed then, when it is changed?

Because blocks and selection are considered transient they don't count as an edit to a record. The content being edited does count but that's not synced right away. The content stays stale in the other collaborator's doc until an autosave happens. That's why the save button doesn't become visible - the post isn't technically dirty.

The screenshot below is from getPostChangesFromCRDTDoc, wherein the first log is when I add some text to a paragraph in another browser session and the second log is a few seconds later when the save becomes visible in the current browser session. The text I added is fd.

So, we should be calling the function that's passed in for calculating the content value using the blocks in the change set. Without that, our content value will always be stale in the doc and so the save button won't really be visible again for other collaborators.