-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Styles Screen: Ensure variations previews will render in mobile viewports #51080
Styles Screen: Ensure variations previews will render in mobile viewports #51080
Conversation
Size Change: +58 B (0%) Total Size: 1.39 MB
ℹ️ View Unchanged
|
onChange={ noop } | ||
onInput={ noop } | ||
> | ||
<div className="edit-site-sidebar-navigation-screen-global-styles__content"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just checking, is the <div />
necessary here too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not necessary, but I copied the same approach as over in the Navigation screen, because if we're wrapping components within content
in this screen, it felt like it might be good to have a container specific to this screen, particularly because we'll likely be adding other components to this screen in follow-ups (e.g. revisions potentially).
Happy to remove it for the moment if you don't think it's warranted for this PR! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What?
Part of #50429
Fix a bug where on mobile viewports, the style variations previews were not rendering in the browse mode Styles screen. Note — this bug would only occur if you're always in a mobile viewport size for the duration of your visit to the site editor. If the editor canvas is at all visible, then the style variations will render, so it's an easy bug to miss when testing in a desktop browser.
Why?
It turns out that for the
Iframe
block editor component to successfully render aniframe
element, it performs a check that the block editor settings are initialised (here). This internal state (__internalIsInitialized
) is set here within theBlockEditorProvider
.In desktop screen sizes, this setting appears to be set already when accessing the Styles screen because the editor canvas has already been rendered, so an editor provider is already in use. However, in mobile viewports, the editor canvas isn't rendered yet, so the state isn't available yet.
Since the previews should have access to settings, etc, I borrowed a similar approach from the Navigation screen introduced in #50840, and added a
BlockEditorProvider
to the global styles screen in browse mode.How?
<StyleVariationsContainer />
in the Styles screen in aBlockEditorProvider
.Testing Instructions
Screenshots or screencast
The below screengrabs depict reloading the Styles screen in the site editor browse mode in a mobile viewport size.