Site Editor: Classic theme site preview flickering

[t-hamano]

Description

In the classic theme, you will see the front-end preview in the site editor.

The admin bar will flash on initial load, likely due to a process to remove it so that it doesn’t appear.

We may want to investigate whether you can eliminate this flickering.

Step-by-step reproduction instructions

• Activate a classic theme.
• Go to Appearance > Design
• Check the initial load of the preview, you can also check by reloading the browser.

Screenshots, screen recording, code snippet

9ffa9a973fbb1dc80156ac5301259b50.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 Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[stokesman]

I’d noticed this and tinkered with some fixes. To me it would seem best to have the page served without an admin bar—using the show_admin_bar filter.

A rough proof of concept diff adding a GET parameter to the site url so it can be served without an admin bar and interactivity disabled.

diff --git a/gutenberg.php b/gutenberg.php
index 9d57e8d2bc..967df52478 100644
--- a/gutenberg.php
+++ b/gutenberg.php
@@ -76,3 +76,22 @@ function gutenberg_pre_init() {
 
 	require_once __DIR__ . '/lib/load.php';
 }
+
+add_action( 'init', function() {
+	if( isset( $_GET['wp-site-editor-preview'] ) ) {
+		add_filter( 'show_admin_bar', '__return_false' );
+		add_action( 'wp_print_footer_scripts', function() {
+			echo '<script>', <<<JS
+				// Make interactive elements unclickable.
+				const interactiveElements = document.querySelectorAll(
+					'a, button, input, details, audio'
+				);
+				interactiveElements.forEach( ( element ) => {
+					element.style.pointerEvents = 'none';
+					element.tabIndex = -1;
+					element.setAttribute( 'aria-hidden', 'true' );
+				} );
+			JS, '</script>';
+		} );
+     }
+} );
diff --git a/packages/edit-site/src/components/editor/site-preview.js b/packages/edit-site/src/components/editor/site-preview.js
index e53f87bc5b..378e4629f8 100644
--- a/packages/edit-site/src/components/editor/site-preview.js
+++ b/packages/edit-site/src/components/editor/site-preview.js
@@ -12,10 +12,10 @@ export default function SitePreview() {
 		return siteData?.home;
 	}, [] );
 
-	// If theme is block based, return the Editor, otherwise return the site preview.
 	return (
 		<iframe
-			src={ siteUrl }
+			tabIndex={ -1 }
+			src={ `${ siteUrl }?wp-site-editor-preview` }
 			title={ __( 'Site Preview' ) }
 			style={ {
 				display: 'block',
@@ -23,26 +23,6 @@ export default function SitePreview() {
 				height: '100%',
 				backgroundColor: '#fff',
 			} }
-			onLoad={ ( event ) => {
-				// Hide the admin bar in the front-end preview.
-				const document = event.target.contentDocument;
-				document.getElementById( 'wpadminbar' ).remove();
-				document
-					.getElementsByTagName( 'html' )[ 0 ]
-					.setAttribute( 'style', 'margin-top: 0 !important;' );
-				document
-					.getElementsByTagName( 'body' )[ 0 ]
-					.classList.remove( 'admin-bar' );
-				// Make interactive elements unclickable.
-				const interactiveElements = document.querySelectorAll(
-					'a, button, input, details, audio'
-				);
-				interactiveElements.forEach( ( element ) => {
-					element.style.pointerEvents = 'none';
-					element.tabIndex = -1;
-					element.setAttribute( 'aria-hidden', 'true' );
-				} );
-			} }
 		/>
 	);
 }

Is that a bad idea for some reason?

[t-hamano]

To me it would seem best to have the page served without an admin bar—using the show_admin_bar filter.

I agree. To handle this on the server side, we need an approach where one of the conditional statements in the is_admin_bar_showing() function returns false.

As far as I know, the only way to do this is to hook into it based on GET parameters. Maybe we can reuse the wp_theme_preview parameter for the block theme preview?

[t-hamano]

I have submitted a core ticket to discuss a backend approach: https://core.trac.wordpress.org/ticket/63076

[t-hamano]

Core PR: WordPress/wordpress-develop#8475

I will also submit a Gutenberg PR soon.