Site Editor: Empty header while in distraction-free mode about gutenberg

[youknowriad]

@ramonjd as an escape hatch, there's already a way to exit this using the command palette. But I'm hoping we can land #61579 to fix this entirely.

[draganescu]

I can imagine some folks might be find themselves unable to revert to "Distraction" mode 😄 I guess this bug has made it to Core a while back.

@ramonjd this has not been shipped in core, it’s been shipped with Gutenberg releases. #61579 will fix this when merged and be back ported to WP.

[Mamaduka]

cc @youknowriad, @draganescu

[youknowriad]

Thanks for catching this. I tried looking and it's a bit challenging. The distraction free "hover" animation is split into two parts:

• the first hover event handler animates the hub (so the hub needs to be 100% wide)
• the second hover event handler animates the header itself

The problem now is that the header is not rendered within the hub anymore, the hover event of the header is not triggered anymore. It seems there's no way to trigger two hover events for elements that are not within each other (one covering the other).

I see two options:

• A hack: simulate a hover event manually on the header when hovering the hub (dispatchEvent)
• A better fix but requires some design changes: Render the hub within the header (rather than keep it on top of the header but visually make it look like it's in the header). The animation when entering and exiting the "edit" mode for the hub becomes harder to achieve.

[draganescu]

@jeryj I think this is worth a look from you as you've been improving this animation a bit in the past as well. Maybe you have more to add to what Riad described above.

[jeryj]

I found a way to share the header animation state via a context and using that variant name to set the animation of the other components. It's far from finished, but it may be a way forward with enough tweaking to be able to use one div to set the animation variant and pass it to the others: #60916

What do you think @youknowriad?

[youknowriad]

For me it's still a hack. The interface skeleton's API has been changed to receive a variant prop for the header? It doesn't make much sense in terms of API for that component.

I'm of the opinion that we should do my proposed hack 1 temporarily and try to implement 2 longer term. In the post editor the "toggle" (hub) or whatever is part of the header, it should be the same in the site editor.

[jeryj]

The interface skeleton's API has been changed to receive a variant prop for the header? It doesn't make much sense in terms of API for that component.

It's less about the API of how things are passed around. I wasn't focused on that. I more mean the design of using consistent variant names and using those variant names to keep all the animation states in line. So, for your recommended hack:

A hack: simulate a hover event manually on the header when hovering the hub (dispatchEvent)

Rather than simulate a hover event manually on the header, set an animation state of a variant name somewhere that can be read by whatever wants to use it.

[youknowriad]

Rather than simulate a hover event manually on the header, set an animation state of a variant name somewhere that can be read by whatever wants to use it.

Yeah I understand and could be fine as a temporary solution but I just don't see why the header animation need to be set on the "layout" hub component. Why would the "layout" of the site editor pass a variation name to the header of a specific page/route of the site editor. The layout shouldn't even know about the registered routes/pages. Ultimately the "shell" of the site editor and the routes/pages will be in completely different packages probably as we'll have other pages in WP-Admin that may use the same "shell".

[jeryj]

I just don't see why the header animation need to be set on the "layout" hub component.

It wouldn't need to be set there. The example I showed is a proof of concept of how setting and reading a variant name might be a good way forwards so we can trigger multiple layers of animations consistently from wherever makes the most sense. I'm not committed to this approach, fwiw. Trying to provide more options that could work.

Render the hub within the header (rather than keep it on top of the header but visually make it look like it's in the header). The animation when entering and exiting the "edit" mode for the hub becomes harder to achieve.

If we go this route, we'd need to make sure the semantics of the page are correct and focus is handled between elements disappearing/appearing.

[draganescu]

👋🏻 given that this is a shipped bug and it's also a bug that prevents action (user is stuck in distraction free, user is stuck with no save/publish) unless they visit the post editor to exit DFM, I would vote to land a hack if the proper solution is too convoluted.

[stokesman]

In anyone subscribed here has some availability you may wish to test the hack I made at #61874 as that fixes this in my testing. I'd like to think it may not be a hack but I don’t comprehend its potential impacts.

UPDATE: Closed that PR. I don’t think we can consider it and its primary purpose wasn’t to fix this issue—it just happened to. The primary thing it meant to fix is better done by #61882 (which unfortunately didn’t impact this).

[ramonjd]

Just noticed this while testing something else.

Is there any way to provide an intuitive and accessible exit for users who activate distraction free mode?

Currently the only way I can find is to use the control panel (Cmd+K) and select Exit Distraction Free.

given that this is a shipped bug and it's also a bug that prevents action (user is stuck in distraction free, user is stuck with no save/publish) unless they visit the post editor to exit DFM, I would vote to land a hack if the proper solution is too convoluted.

💯

I can imagine some folks might be find themselves unable to revert to "Distraction" mode 😄 I guess this bug has made it to Core a while back.

I can only speak for myself, but it's pretty frustrating.

Even a persistent snackbar with "Exit" or "Undo" would help, or removing the feature entirely from the Site Editor. Example:

diff --git a/packages/editor/src/store/actions.js b/packages/editor/src/store/actions.js
index d934436800..94643aaaf2 100644
--- a/packages/editor/src/store/actions.js
+++ b/packages/editor/src/store/actions.js
@@ -15,6 +15,7 @@ import { store as blockEditorStore } from '@wordpress/block-editor';
 import { applyFilters } from '@wordpress/hooks';
 import { store as preferencesStore } from '@wordpress/preferences';
 import { __ } from '@wordpress/i18n';
+import { getPath } from '@wordpress/url';
 
 /**
  * Internal dependencies
@@ -737,6 +738,9 @@ export const toggleDistractionFree =
 		const isDistractionFree = registry
 			.select( preferencesStore )
 			.get( 'core', 'distractionFree' );
+		const isSiteEditor = getPath( window.location.href )?.includes(
+			'site-editor.php'
+		);
 		if ( isDistractionFree ) {
 			registry
 				.dispatch( preferencesStore )
@@ -764,9 +768,17 @@ export const toggleDistractionFree =
 					{
 						id: 'core/editor/distraction-free-mode/notice',
 						type: 'snackbar',
+						/*
+						 * Persist the snackbar in the case of Distraction Free mode.
+						 * There is a bug where the header is not visible in the Site Editor.
+						 * See: https://github.com/WordPress/gutenberg/issues/60875
+						 */
+						explicitDismiss: isSiteEditor && ! isDistractionFree,
 						actions: [
 							{
-								label: __( 'Undo' ),
+								label: isDistractionFree
+									? __( 'Undo' )
+									: __( 'Exit' ),
 								onClick: () => {
 									registry.batch( () => {
 										registry

In action:

2024-06-05.15.37.16.mp4

I can get a PR up if folks agree it's a decent interim move. I'd also look into adding a prop to the snackbar component to explicitly hide the close button.

[ramonjd]

Ah gotcha, thanks for the feedback @draganescu and @youknowriad 🙇🏻