Visual Revisions: Autosave view incorrectly highlights unchanged base blocks and empty blocks as new additions

[habiburdev]

Description

Following the new Visual Revisions improvements introduced in the WordPress 7.1 testing cycle, there is a visual regression in the diff highlighting engine when previewing an autosave notice on a clean core installation.

Expected Behavior

Entering the modern Visual Revisions side-by-side panel layout should isolate only the specific blocks containing newly altered or freshly added content, highlighting them with a green border and background while leaving untouched baseline content un-highlighted.

Actual Behavior

The visual comparison canvas mistakenly applies green addition highlights across the entire block list. The unchanged baseline text block (e.g., the default "Welcome to WordPress..." text), the newly added text block, and even a trailing empty block are all wrapped in green addition borders simultaneously. This failure to isolate state modifications completely defeats the clarity and utility of the visual diff view.

Step-by-step reproduction instructions

1. Set up a clean test site running WordPress 7.1-beta1 with NO active plugins (native core environment).
2. Open an existing, published post (such as the default "Hello world!" post which contains the baseline "Welcome to WordPress..." paragraph block).
3. Insert a new Paragraph block below the baseline text and type "Autosave test content". Do not touch or modify the original baseline paragraph.
4. Force a server autosave via the developer console using wp.data.dispatch('core/editor').autosave();.
5. Immediately refresh the browser tab without manually clicking the core update button.
6. On the resulting admin warning notice banner, click the "View the autosave" link to enter the Visual Revisions interface.
7. Observe the visual diff canvas highlights.

Screenshots, screen recording, code snippet

Environment info

• WordPress Core: 7.1-beta1
• Gutenberg Plugin: None (Deactivated / Core Native)
• Configuration: Clean install via WordPress Playground
• Browsers Tested: Chrome (Latest)
• OS: macOS

---

Context / Related:

• Part of the WordPress 7.1 Visual Revisions polish cycle tracking testing metrics.
• Follow tracking issue: Visual Revisions: post-7.0 polish #79120
• Related to PRs: Visual revisions: Make the autosave notice work with the visual revisions UI #79947 and Visual revisions: Label autosaves in the revisions timeline #79950

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

[himanshupathak95]

This was actually flagged by @annezazu during the #79947 review but deferred.

Root cause I think is that the autosaves live in a separate REST endpoint (/autosaves) and a separate core-data store slice. When setCurrentRevisionId(autosaveId) is called, both getCurrentRevision() and getPreviousRevision() call getRevisions(), which never includes autosave records, and both resolve to null. This feeds two empty strings into diffRevisionContent(), producing zero matched blocks and tagging every rendered block as "added."

So, in use-revision-blocks.js, maybe we can detect when the current ID is an autosave and source content from getAutosave() (already in core-data) diffed against the published post's content. As a quick guard: skip diff highlighting when the revision lookup returns null, rather than showing false-positive green on everything.