You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
AI Admin Pages Exhibit Visible Flicker During Initial Render #741
AI-related admin screens exhibit a noticeable visual flicker during page navigation and initial render. When navigating to the AI or Connectors pages, the existing admin UI is briefly replaced by a black/blank screen before the page content is rendered.
In contrast, standard WordPress admin pages transition smoothly without any visible intermediate state. This creates an inconsistent user experience and gives the impression that AI pages are slower or undergoing a full-page reload.
Environment
WordPress AI Plugin: Version 1.0.2
Environment: WordPress Playground
Browser: Chrome V 149.0.7827.115
Notes
Reproduced consistently on a fresh WordPress Playground instance.
The issue appears to be specific to AI-related pages and not the general WordPress admin experience.
This may indicate a loading-state, rendering, or hydration issue during page initialisation.
No functional issues were observed; this is primarily a UX/performance concern.
Step-by-step reproduction instructions
Steps to Reproduce
Launch a fresh WordPress Playground instance.
Install and activate the latest version of the AI plugin.
Navigate between standard WordPress admin pages (Dashboard, Posts, Pages, Plugins, etc.).
Observe that pages load normally without any visual flash.
Navigate to:
AI
Connectors
Observe the page loading behavior.
Screenshots, screen recording, code snippet
Recording.1864.mp4
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except the AI plugin.
Yes
Please confirm which theme type you used for testing.
I looked into this locally. The flicker appears to come from the inline critical styles in the generated AI admin page, where #wpwrap is given a dark background:
On initial load, before the boot module mounts the app into .boot-layout-container, the CSS variable isn't available yet, so the #1e1e1e fallback paints the entire wrap dark for a moment producing the black flash before content renders.
Since this lives in an auto generated page file (driven by the boot/routes build), it likely needs to be addressed at the source rather than the generated output. Sharing in case it helps narrow down the fix.
Yeah, I believe there's a related issue in the Gutenberg repo that looked at fixing this on the Connectors screen, perhaps isn't released yet but finding that and mimicking on the AI settings page is probably best.
WordPress/gutenberg#74572 is all I found in searching quickly, but that's not the one I had remembered so some more searching is worthwhile before trying to change anything within the AI plugin.
I think WordPress/gutenberg#78493 is the PR about black flash in wp-build. Also, the package is "@wordpress/build": "^0.16.0" here in package.json and latest version is 0.16.1.
For me, the following steps worked locally:
Update the package npm update @wordpress/build
Rebuild the routes npm run build:routes
Open build/pages/ai/page-wp-admin.php and confirm the #wpwrap block no longer has background css.
We may need to update the package.json and package-lock.json
I haven't had time to pull and test locally, but from the screencast it looks like the flicker is still there, it just no longer has the black overlay.
Yes, in Gutenberg, only the black flash has been fixed by updating the wordpress/build. So for now, I've updated it, but I think we need to investigate the flicker further. The same flicker is present in Gutenberg as well.
Activity
Trushiv04 commentedon Jun 18, 2026
I looked into this locally. The flicker appears to come from the inline critical styles in the generated AI admin page, where
#wpwrapis given a dark background:#wpwrap { background: var(--wpds-color-fg-content-neutral, #1e1e1e); }On initial load, before the boot module mounts the app into
.boot-layout-container, the CSS variable isn't available yet, so the#1e1e1efallback paints the entire wrap dark for a moment producing the black flash before content renders.Since this lives in an auto generated page file (driven by the boot/routes build), it likely needs to be addressed at the source rather than the generated output. Sharing in case it helps narrow down the fix.
jeffpaul commentedon Jun 18, 2026
Yeah, I believe there's a related issue in the Gutenberg repo that looked at fixing this on the Connectors screen, perhaps isn't released yet but finding that and mimicking on the AI settings page is probably best.
jeffpaul commentedon Jun 18, 2026
WordPress/gutenberg#74572 is all I found in searching quickly, but that's not the one I had remembered so some more searching is worthwhile before trying to change anything within the AI plugin.
prasadkarmalkar commentedon Jun 21, 2026
I think WordPress/gutenberg#78493 is the PR about black flash in wp-build. Also, the package is
"@wordpress/build": "^0.16.0"here in package.json and latest version is0.16.1.For me, the following steps worked locally:
npm update @wordpress/buildnpm run build:routesWe may need to update the package.json and package-lock.json
Screencast
Screen.Recording.2026-06-21.at.6.10.48.PM.mov
justlevine commentedon Jun 22, 2026
I haven't had time to pull and test locally, but from the screencast it looks like the flicker is still there, it just no longer has the black overlay.
prasadkarmalkar commentedon Jun 23, 2026
Yes, in Gutenberg, only the black flash has been fixed by updating the wordpress/build. So for now, I've updated it, but I think we need to investigate the flicker further. The same flicker is present in Gutenberg as well.
ankitguptaindia commentedon Jun 23, 2026
Latest Test Status: #754 (comment)
jeffpaul commentedon Aug 10, 2026
@prasadkarmalkar have things improved in Gutenberg such that a package update will resolve things here?