View transition admin bar quirks

[zieladam]

Since 7.0 enabled view transitions in wp-admin (#64470, ​PR 10699), navigating between admin screens crossfades the entire admin sidebar into itself, even when its markup is nearly identical between the two pages.

Screencast: ​https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-95e0-aec80463dcde

Steps to reproduce

1. Run trunk in Chrome.
2. Log in to wp-admin.
3. Click between two screens whose sidebars are nearly identical (e.g. Dashboard → Posts → Pages).

Expected

Sidebar stays visually stable across the navigation — nothing in it has changed.

Actual

The whole sidebar crossfades between two identical snapshots.

Notes

Claude claims, to be verified:

• src/wp-admin/css/view-transitions.css gives each top-level menu item a stable view-transition-name, but #adminmenu itself does not — so the whole sidebar falls into the default root snapshot and crossfades on every navigation.
• a likely fix is to give #adminmenu (and possibly #adminmenuwrap) its own view-transition-name so it's treated as a single persistent element across navigations rather than part of the default root snapshot.

cc @westonruter @annezazu

[mukesh27]

Screencast: ​https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-95e0-aec80463dcde

Not working. Update the URL please

[westonruter]

Replying to zieladam:

Screencast: ​https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-95e0-aec80463dcde

This is a 404. Can you upload here?

[zieladam]

Oh! It works on my end, even in private mode. How weird! I couldn't upload here because of the 10MB limit, but I've uploaded it to my site, which uploaded it to VideoPress. Hopefully this works:

​https://videos.files.wordpress.com/Lnml4hak/574645931-7a48ae52-70d7-47ee-95e0-aec80463dcde.mp4

[westonruter]

@zieladam I'm struggling to see the exact issue from your video. I'm seeing a bit of a flicker in the admin bar, for example when navigating from the Dashboard to the Posts screen. Is that what you're referring to? I think this may be due to Command Palette node since it is revealed/populated with JavaScript with the page loads. We might want to hold painting until DOM load. See ​Anti-flickering in the View Transitions repo.

Closely related to this is the issue of Admin Notice instability (#45186, comment). This may be a workaround, however, for a more fundamental issue.

[joedolson]

I'm removing the accessibility focus from this; for accessibility purposes, this is resolved by the existing support for prefers-reduced-motion and otherwise doesn't have any additional impact beyond any other aspect of the view transition animation.

Fixes the admin menu flicker/crossfade during view transitions by giving the sidebar containers stable view-transition-name values.

## Testing

• Run trunk in Chrome.
• Log in to wp-admin.
• Navigate between screens with similar sidebars, for example Dashboard -> Posts -> Pages.
• Confirm the admin menu is no longer treated as part of the root transition snapshot.

## Notes

• Verified locally that #adminmenuwrap and #adminmenuback receive separate view-transition groups during navigation in Chrome via Playwright/runtime inspection.

[dhrupo]

PR opened for review: ​https://github.com/WordPress/wordpress-develop/pull/11582

This patch gives #adminmenuwrap and #adminmenuback stable view-transition-name values in src/wp-admin/css/view-transitions.css so the admin menu is not left entirely in the root transition snapshot during admin navigation.

Testing performed:

• Reproduced on trunk in Chrome while navigating between Dashboard -> Posts -> Pages.
• Verified locally that the patched CSS is applied.
• Verified via Playwright/runtime inspection that #adminmenuwrap and #adminmenuback receive separate view-transition groups during navigation.

Keywords: has-patch needs-testing

[audrasjb]

We now have a PR that needs-testing.
I'm self assigning this ticket as it doesn't have any owner yet, but more tests are welcome! 🧪

[nikunj8866]

Test Report

Description

✅ This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11582

Environment

• WordPress: 7.1-alpha-20260416.035027
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 147.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps to Test

1. Open the pull request: ​https://github.com/WordPress/wordpress-develop/pull/11582
2. Click "Test this pull request with WordPress Playground." to launch WordPress Playground.
3. Navigate between admin pages with similar sidebars: Dashboard > Posts > Pages
4. Observe the sidebar during navigation transitions.

Actual Results

1. ✅ Issue resolved with patch.
2. The admin sidebar should remain visually stable during navigation.

Supplemental Artifacts

Before Patch: ​https://www.awesomescreenshot.com/video/51776620?key=76470c3ab3ab51bc2d86bdbab37c53cd
After Patch: ​https://www.awesomescreenshot.com/video/51776671?key=6079e6fdbfcfe82cd66485a3f9683a2d

[darshitrajyaguru97]

Test Report

Description

✅ This report validates that the indicated patch works as expected in a different PHP environment.

• Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11582

Environment

• WordPress: 7.1-alpha-20260416.035027
• PHP: 7.4.33
• Server: Apache
• Database: MySQL
• Browser: Chrome
• OS: Windows
• Theme: Twenty Twenty-Five
• MU Plugins: None activated

Steps to Test

# Applied the patch
# Navigated between admin pages with similar sidebars (Dashboard → Posts → Pages)
# Observed the sidebar during navigation transitions

Actual Results

✅ Issue resolved with the patch.

• The admin sidebar remains visually stable during navigation.

Expected Results

• The admin sidebar should remain visually stable during navigation.

Conclusion

• The patch works as expected on PHP 8.2
• Confirms compatibility beyond the originally tested PHP 7.4 environment

After applying this patch, I noticed an issue. you can check it in the video.

​https://github.com/user-attachments/assets/c7f2b092-b5ca-45d2-b42d-83741f234b25

Confirmed this is a valid issue. #adminmenuback is a fixed background layer, and giving it its own view-transition-name can produce a bad transition snapshot. I pushed c06aea7590 to narrow the patch so only #adminmenuwrap participates, while leaving the menu item transition names in place.

In my 7.1-alpha-62328 test installation, I noticed visual bugs in the nav sidebar. The expanding sub-nav section seems to be a bit unsmooth and the sub-nav items are jumping a bit. Take a look:

​https://github.com/user-attachments/assets/ce79c7a4-e7ce-4f69-b16e-aef97a1a5884

Google Chrome - Version 147.0.7727.138 on MacOS 26.4.1

[audrasjb]

Thanks for the PR but to be honest, in my testing I'm not sure I can see any difference between the current visual implementation and the one proposed in the PR, and how it's supposed to improve the navigation. I was about to share two before/after videos but the visual feeling is pretty the same. Does anyone notice any difference before/after the patch is applied?

[nikunj8866]

@audrasjb I've shared before/after screencasts here: https://core.trac.wordpress.org/ticket/65032#comment:14

[audrasjb]

@nikunj8866 Hmm, in these screencasts, it looks like you compare 6.9 to 7.0 with this patch. Of course the transition is more fluid with the patch.

My point is that when you compare 7.0 without and with this patch, I don't see any difference.

[westonruter]

I zoomed in to the original and stepped through it frame-by-frame at around 2 seconds into the video. See admin-bar-view-transition-slow-motion.mp4​.

@zieladam Please confirm this is what you were referring to: The dashicons in the admin bar appear to not be initialized when first landing on the target page, which causes the admin bar items to appear to shift left and right during some navigations.

I think I can reproduce this locally, but:

1. I have to open DevTools, and
2. I have to enable 4x CPU throttling, and
3. I have to disable cache.

So this all seems to boil down to rendering delay for the Dashicons font. Given that the font will be loaded on the first admin page view and subsequent page views will have it in cache (unless you've disabled cache via DevTools), then I do not think this is an actual issue that users will experience.

So I'm suggesting that we close this as worksforme.

[audrasjb]

Pending closure decision, I'm moving this to 7.0.1.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[zieladam]

@westonruter I was referring to:

1. The dashicons in the admin bar shifting left and right
2. The left sidebar cross-fading from one state to the other on some navigations, and cross-fading+using an accordion-like animations on other navigations. I would expect it to only use that accordion effect to hide one part of the sidebar and expand another. That motion tells me what is happening. The cross-fade makes it confusing, as in I'm left wondering "what just happened? what changed?"

When view transitions were enabled throughout wp-admin in 7.0, each top-level admin menu item was given a stable view-transition-name, so navigating between sections animates them into place (the "accordion" effect). Two rough edges remained in that animation:

• A newly-current section's submenu was captured at its full intrinsic height, so it painted at full height from the first frame and overlapped the menu items below while they were still sliding down into place.
• The collapse button (#collapse-menu) was not named, so it cross-faded as part of the page root instead of moving with the rest of the menu.

## Changes

• Add a shared view-transition-class (wp-menu-top) to every top-level menu item, and set overflow: clip on ::view-transition-image-pair(.wp-menu-top). This clips each menu-top's snapshot to its animating group box, so an expanding submenu wipes open from the link row to full height — and wipes closed in reverse — in step with the items below it, instead of overlapping them.
• Give #collapse-menu its own view-transition-name so it slides into place with the menu items rather than cross-fading via the root.
• Add code comments explaining each rule.

This touches src/wp-admin/css/view-transitions.css only — no markup or behavior changes.

## Testing instructions

1. In Chrome, with the OS "reduced motion" setting off, log in to wp-admin.
2. Navigate between sections whose submenus differ — e.g. Dashboard → Posts → Appearance.
3. Observe the left menu: the previously-open submenu should wipe closed and the newly-current one wipe open, staying in step with the surrounding top-level items. Before this change the expanding submenu briefly overlapped the items beneath it.
4. Confirm the "Collapse menu" button slides with the menu rather than fading.

In the following videos, I have a plugin active which slows down the animations to make them more observable:

add_action(
        'admin_print_styles',
        function () {
                ?>
                <style>
                        /* TEMP DEBUG: slow every view transition animation down to 2s. Remove before shipping. */
                        ::view-transition-group(*),
                        ::view-transition-old(*),
                        ::view-transition-new(*) {
                                animation-duration: 1s;
                        }
                </style>
                <?php
        }
);

# Before:

​https://github.com/user-attachments/assets/c38df09e-78e7-46b4-bf79-264d30d93ec2

# After:

​https://github.com/user-attachments/assets/653779de-3cb6-4404-a736-27c3d1fe1c55

[westonruter]

Replying to zieladam:

@westonruter I was referring to:

1. The dashicons in the admin bar shifting left and right

So is this not actually an issue given what I shared in my comment?

2. The left sidebar cross-fading from one state to the other on some navigations, and cross-fading+using an accordion-like animations on other navigations. I would expect it to only use that accordion effect to hide one part of the sidebar and expand another. That motion tells me what is happening. The cross-fade makes it confusing, as in I'm left wondering "what just happened? what changed?"

I think I see what you mean. I see two issues:

1. The submenu doesn't actually change its height when transitioning between open and closed states. So when transitioning from open to closed, fading submenu appears overlaid on top of subsequent menu items.
2. The "Collapse Menu" was not getting its own view transition snapshot, causing it to only fade between page navigations and not animate into place.

I've opened ​https://github.com/WordPress/wordpress-develop/pull/11912 to fix these issues.

Nevertheless, I still see occasionally that when navigating from Settings to Users that there is a lack of an accordion animation on the submenu. A fade only happens sometimes. I haven't identified specifically what the issue is.

🤖 From ​Claude Code — paired with @westonruter on this branch. Posting this to document how the root cause was found, since the render-blocking fix isn't obvious without the backstory.

## Diagnosing the intermittent accordion failure

Symptom. Navigating between admin sections, the menu "accordion" (one section's submenu collapsing as the next expands) usually played, but _intermittently_ degraded to a plain cross-fade with no movement. It was hard to reproduce — and, crucially, it happened more often with DevTools closed.

Ruled out along the way:

• Scroll position. The admin menu scrolls with the page when it is taller than the viewport, so a scroll delta between two loads can translate the whole menu. This was confirmed as a real mechanism via a controlled same-document transition — but the bug also occurs with a fixed, top-aligned menu, so it was not the cause here.
• Overlapping navigations. Clicking again before the previous (~0.25s) transition finished could interrupt it. Instrumentation ruled this out: the failing navigations were clean push navigations with priorTransitionStillRunning: false.

Instrumentation. A temporary pagereveal / pageswap logger recorded, for every navigation, each menu item's captured old/new view-transition snapshot heights plus context (readyState, navigation type, whether a prior transition was still running). Because the bug reproduced best with DevTools _closed_, each failing navigation was persisted to localStorage so it could be captured without DevTools open and inspected afterward.

Root cause. Every captured failure showed the same two things: readyState: "loading", and an incomplete admin menu — e.g. only 7 of the 11 .menu-top items existed, or none at all.

A cross-document view transition snapshots the _incoming_ page at its first render, and the browser paints incrementally — so first paint (and therefore the snapshot) can happen before the <body> has finished parsing. When it does, the admin menu is only half-built in the snapshot; the items that should change height are not there yet, so there is no geometry delta to animate and the transition falls back to a plain cross-fade. "More often with DevTools closed" fits exactly: a faster load lets first paint beat the body parse.

Fix. A render-blocking expectation in the admin <head>:

<link rel="expect" href="#wpfooter" blocking="render" media="(prefers-reduced-motion: no-preference)">

This holds the first render — and so the view transition's snapshot — until #wpfooter (the end of the body) has parsed, guaranteeing the snapshot captures a fully-built page. The media query confines the small first-render delay to when view transitions actually run.

The two CSS refinements in the first commit — clipping each menu item's snapshot so a submenu _wipes_ open/closed instead of overlapping the items below, and naming #collapse-menu so it moves with the menu — were found and fixed during the same investigation.

[westonruter]

Replying to westonruter:

Nevertheless, I still see occasionally that when navigating from Settings to Users that there is a lack of an accordion animation on the submenu. A fade only happens sometimes. I haven't identified specifically what the issue is.

@zieladam Thanks to the Chrome DevTools MCP server with Claude Code, I found ​the reason for the sporadic failure to animate and fixed it. I'm now getting consistent submenu accordion animations with each navigation.

[ozgursar]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11912

Environment

• WordPress: 7.1-alpha-62161-src
• Subdirectory: No
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 148.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.5
• MU Plugins: None activated
• Plugins:
  • Code Snippets 3.9.6
  • Test Reports 1.3.0

Steps taken

1. Install the following plugin provided by @westonruter to slow down animations and observe the changes easily.

<?php
add_action(
        'admin_print_styles',
        function () {
                ?>
                <style>
                        /* TEMP DEBUG: slow every view transition animation down to 2s. Remove before shipping. */
                        ::view-transition-group(*),
                        ::view-transition-old(*),
                        ::view-transition-new(*) {
                                animation-duration: 1s;
                        }
                </style>
                <?php
        }
);

2. Navigate between menu items when Dev Tools is closed and observe the cross fade as well as the position of Collapse Menu between transitions.
3. Apply patch and observe the transitions again.
4. Confirm the expanding submenu wipes open in step with the surrounding menu items, rather than briefly overlapping the items beneath it.
5. Confirm the "Collapse menu" button slides with the menu rather than fading
6. ✅ Patch is solving the problem.

Expected result

• Submenu wiping closed, the new one wiping open should play on every navigation, never degrading to a plain cross-fade.
• Collapse menu item should slide with the menu.

Additional Notes

Before patch:
​https://files.catbox.moe/zyrbdf.mp4

After patch:
​https://files.catbox.moe/iwpnsq.mp4

@mukeshpanchal27 How's this look to you?

@mukeshpanchal27 Hummm. I was able to reproduce this once, but then I couldn't reproduce it anymore. Is this reliably reproducible?

@mukeshpanchal27 Hummm. I was able to reproduce this once, but then I couldn't reproduce it anymore. Is this reliably reproducible?

Yes. In ​Test this pull request with WordPress Playground instance.

[masteradhoc]

As the RC for WP 7.0.1 is expected to land tomorrow we'll have to punt this to 7.0.2.

[westonruter]

Re-milestoning for 7.1, but recognizing this may now get moved to 7.2.

[wildworks]

I'd like to punt this to 7.2 as the commit freeze for 7.1 RC1 is only a few hours away.