Repository navigation
Visual Revisions: Autosave view incorrectly highlights unchanged base blocks and empty blocks as new additions #80455
Description
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
- Set up a clean test site running WordPress 7.1-beta1 with NO active plugins (native core environment).
- Open an existing, published post (such as the default "Hello world!" post which contains the baseline "Welcome to WordPress..." paragraph block).
- Insert a new Paragraph block below the baseline text and type "Autosave test content". Do not touch or modify the original baseline paragraph.
- Force a server autosave via the developer console using
wp.data.dispatch('core/editor').autosave();. - Immediately refresh the browser tab without manually clicking the core update button.
- On the resulting admin warning notice banner, click the "View the autosave" link to enter the Visual Revisions interface.
- 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
Activity
himanshupathak95 commentedon Jul 20, 2026
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.
Intenzi commentedon Sep 23, 2026
I have implemented a suitable fix in PR #83342
It uses the current post content when there are no previous revisions to compare against. (For example a default installation post such as Hello world or a Draft post). Thus ensuring that the entire post is not highlighted as green and only valid changes are highlighted.