Post Revisions: Disable Restore on a revision matching the post

[sanketio]

What?

Closes #81401

Disables the "Restore" button in the Post Revisions view when the selected revision already matches the saved post, so the current version is no longer offered as restorable.

Why?

The revisions view opens on the newest revision, which is a copy of the post as it was last saved. Restore was enabled there anyway, because the only condition was:

const canRestore = !! currentRevisionId;

Clicking it ran a full editPost + savePost round-trip that changed nothing and then reported Restored to revision from %s. as if a restore had happened. As the reporter put it, "I expected the Restore button to be disabled or something since there is nothing to restore."

How?

hasChangesToRestore() compares the fields restoreRevision writes back — content, title and excerpt raw values, plus the meta keys the revision carries — against the saved post, and the button is disabled when they all match.

Two details drove that shape, both established by measurement rather than assumption (full write-up in the issue):

It does not compare revision IDs. Disabling when the selection equals getCurrentPostLastRevisionId() looks like the obvious fix, but while an autosave exists it is the post's latest revision — verified through REST, where predecessor-version pointed at the autosave and the collection was [60, 59]. An ID comparison would refuse to restore an autosave, which is exactly what the "View the autosave" flow in use-autosave-notice.js enters revisions mode to do. Comparing content instead handles autosaves with no special-casing, since an autosave is simply a revision whose content differs.

It skips protected meta. Comparing meta wholesale never disables the button at all. Measured on a post whose newest revision matched it exactly:

content equal? true    title equal? true    excerpt equal? true

POST meta: {"_crdt_document":"{\"document\":\"AAAV46m+ix0Oqp…\",\"updateId\":151275664}","footnotes":""}
REV  meta: {"_crdt_document":"","footnotes":""}

Revisions do not preserve the collaborative editing document, so _crdt_document differs on every revision. Underscore-prefixed keys are internal bookkeeping rather than authored content, so they are excluded; public meta such as footnotes is still compared.

Notes for review

• The comparison is byte-exact, so a revision that renders identically but was serialized differently still shows Restore enabled. That is the safe direction — it never wrongly blocks a restore.
• restoreRevision itself is unchanged, so a programmatic call can still produce the no-op save. Happy to add a guard there if you would rather the action be authoritative.
• The disabled button carries no explanation of why, since that would need a new translatable string. Worth a follow-up if wanted.

Testing Instructions

Run the unit tests for the changed component:

npm run test:unit -- packages/editor/src/components/post-revisions-preview

Then, manually:

1. Create a post, then edit and save it two or three times so it has several revisions.
2. Open the Settings sidebar and click Revisions (N). The view opens on the newest revision.
3. Expected: "Restore" is disabled. On trunk it is enabled, and clicking it shows a "Restored to revision from …" snackbar with nothing having changed.
4. Move the slider to an older revision. Expected: "Restore" becomes enabled.
5. Click "Restore" on that older revision. Expected: it restores as before — this PR does not change restoring itself.

To check the autosave path is unaffected: with a published post open, let an autosave happen, reload, and use "View the autosave" in the notice. Expected: "Restore" is enabled, because the autosave differs from the post.

Testing Instructions for Keyboard

The button uses accessibleWhenDisabled, so it stays reachable when disabled. Tab to the "Restore" button in the revisions header: on the newest revision it should be focusable and announced as disabled, and pressing Enter or Space should do nothing. On an older revision it should be focusable and activate normally.

Screenshots or screencast

Before	After
"Restore" enabled on the current version; clicking it reports a successful restore with no change.	"Restore" disabled on the current version; still enabled on every older revision.

Use of AI Tools

The root-cause analysis, the diagnostic instrumentation used to gather the REST and meta measurements above, and this patch were drafted with AI assistance (Claude Code). All reproduction and verification was performed by me on my own machine, and I have reviewed the change and take responsibility for it.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: sanketio <sanketparmar@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: jordesign <jordesign@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @sanketio! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.