-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Interface Skeleton: Limit the Editor Interface to max-width: 100% #26552
Conversation
…locks managing to exceed the width
Size Change: +18 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
TestsFunctionality
Browsers
In IE11, I'm seeing a I'll be double-checking the full screen mode for other blocks and update this comment as I progress.
|
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.
I'm not sure how to justify this solution/workaround, but it works, and it doesn't seem to cause regressions.
I'm not certain if this is the best solution either, but I can confirm that it fixes the issue and doesn't appear to cause regressions in the interface layout or block width settings. Approving this for now, but I'll continue testing other blocks and thinking about why the width: 100%
style addresses the issue.
For context, this regression was introduced at #25884 which made a few changes to the grid model and positioning elements of the interface package. The interface package has a wide reach as it's used by all editors, so I'd welcome that we gain some more understanding of what happened in 25884 and why this fixes it before landing this PR. cc @jorgefilipecosta @jasmussen for thoughts. |
@nosolosw Totally agree with this. I'm keeping this PR un-merged until we have more clues on what's happening. Unfortunately, debugging this issue is complicated. For context, the issue causes the whole editor to be unusuable, as its width too becomes extremely large, moving all centered elements (the title and all the correctly sized blocks) millions of pixel to the right, making the editor look completely blank. When I investigated the issue, I stumbled upon a Stack Overflow thread mentioning that 33554400 is the maximum possible width value of some browsers. Curiously enough, I had to set the width to cc @fullofcaffeine @ockham who were involved with the issue and the temporary fix on Jetpack, and might have some additional insights, or ideas about this. |
After lots of investigation, here's what I've uncovered so far: The more I look into the cause, the more it seems like the issue lies with the Swiper JS library. In a demo with Swiper, I can reproduce an error similar to what we saw in the Jetpack slideshow block. That is to say, I can recreate a problem where swiper slides are set to a width of
One thing to note about the demo is that it uses version 4.3.3 of swiper. I plan to recreate another demo with an updated version tomorrow. |
It's late here and I think this writeup might need more clarity. I'll return to it in the morning to continue editing, but hopefully the gist of it is understandable. There's still more investigation to be done, but digging into swiper js source code, I see a few things that should be noted:
My best guess as to what's happening is that some calculation in I'm still uncertain as to why |
The same issue appears to affect the CoBlocks Post Carousel block: (reported by @mrfoxtalbot) |
Thanks a lot for your research, @jeyip ❤️ |
I've started looking into the issue with the CoBlocks Post Carousel block, and it seems it's exactly the same problem, down to the same Both Jetpack Slideshow and CoBlocks Post Carousel are "slider" blocks, but they use different external libraries: the former uses Swiper, the latter Slick. |
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.
I can not say for sure that this PR did not cause any regression. But in the tests, I did in edit-widgets, edit-site, and edit-post both in desktop and mobile views things worked well and the PR fixes the issues identified so I guess it could be merged.
We could use some help figuring out the intermittent failures here. The reusable blocks one for instance. |
…locks managing to exceed the width (#26552)
* Cover block: Restore default overlay background (#26569) * Restore default Cover overlay background The default Cover block overlay background was removed. This changed the style of existing blocks on existing sites. Restore the default background in such a way that it does not conflict with theme-provided background-color styles and there is no need to artificially add extra specificity. Fix regression: #26545 * Limit the interface skeleton to a max width of 100% to prevent some blocks managing to exceed the width (#26552) * Cover Block: Restore opacity controls (#26625) * Fix image block centering when resizing to a smaller size (#26376) * Fix image block centering when resizing to a smaller size * Revert previous 100% width fix * Remove display: table when image block is resized to avoid centering of block * Match frontend classes for alignment in editor * Gallery: Remove caption fallback for alt attribute (#26676) * Fix quote block default alignment (#26680) * Gallery: Remove obsolete deprecation entry (#26736) * Do not apply text color if it is being overriden (#24626) * Fix: Preset colors don't work on button block style outline (#26707) * Tests: Add fixture for Column deprecation (#26774) * Fix/column width units (#26757) * Fix issues with different units in column widths * Columns with fixed width should keep width on recalculation * Address review feedback * fix undefined index notice in Social Link Block (#25663) * fix undefined index notice * use isset instead of array_key_exists check * Update packages/block-library/src/social-link/index.php Co-authored-by: Greg Ziółkowski <[email protected]> Co-authored-by: Greg Ziółkowski <[email protected]> * Adds in missing styling for toolbar when using text-only setting (#26769) * Adds in missing styling for toolbar when using text-only setting * Increases margin * Moves style to correct file * Inserter: Fix 'Browse All' in Quick Inserter (#26443) * Inserter: Fix 'Browse All' in Quick Inserter Maintain the insertion point in @wordpress/block-editor state when moving from the Quick Inserter to the Inserter. This fixes a bug where the insertion point is wrong after clicking a block appender and selecting 'Browse All'. Care is taken to not regress a previous bug where the insertion point is wrong after clicking an inline insertion button and selecting 'Browse ALl'. * Inserter: Fix typo Co-authored-by: Daniel Richards <[email protected]> * Call getBlockInsertionPoint once * Add useSelect dependencies * Make setInsertionPoint unstable * Avoid setting `isVisible` state when `SET_INSERTION_POINT` is triggered * Make index required and clarify rootClientId usage * Split insertionPoint into two reducers * Fix getInsertionPoint selector that expects default state of reducer to be null * Avoid resetting insertionPoint state on HIDE_INSERTION_POINT Co-authored-by: Daniel Richards <[email protected]> Co-authored-by: Jon Surrell <[email protected]> Co-authored-by: Jacopo Tomasone <[email protected]> Co-authored-by: Daniel Richards <[email protected]> Co-authored-by: Bernie Reiter <[email protected]> Co-authored-by: Greg Ziółkowski <[email protected]> Co-authored-by: Oliver Juhas <[email protected]> Co-authored-by: Jorge Costa <[email protected]> Co-authored-by: Fabian Kägy <[email protected]> Co-authored-by: Tammie Lister <[email protected]> Co-authored-by: Robert Anderson <[email protected]>
) * Set toggle and nav panel as first element in interface skeleton * Position sidebar toggle alongside header topbar * Add site and content wrappers to interface skeleton Previously, the navigation panel and navigation toggle lived within skeleton__body and skeleton__header, respectively. In order to address unexpected keyboard focus order between the nav toggle and nav panel, we create a new element inside of interface-skeleton called skeleton__navigation-sidebar. To account for the layout changes of introducing a new element, we add two wrapper classes: skeleton__site and skeleton__content. Both ensure that the skeleton__header and skeleton__body shrink their children correctly when the navigation sidebar is open. * Add and remove padding to ensure document settings title is centered * Remove toggle from flow of page when sidebar is closed The navigation sidebar lives alongside the skeleton header and skeleton body. This is to ensure that the children of the body and header shrink when the navigation sidebar is open. The problem is that when the navigation sidebar is closed, the skeleton body (i.e. the block editor) no longer spans the entire width of the viewport. The sidebar (and toggle) occupy space at the edge of the screen. To address this, we position the navigation toggle absolutely when the sidebar is closed. * Refactor navigation sidebar directory structure Because navigation panel and navigation toggle live outside the header and body, we place both components in their own navigation sidebar directory * Update scss references * Update navbar-toggle references * Modify z index of footer * Remove unnecessary comment * Remove interface-interface-skeleton__layout * Use interface-skeleton as container * Rename skeleton__site to skeleton_editor * Rename skeleton__navigation sidebar to drawer * Remove comment * Use z-index mixin for interface-skeleton__footer * Use z-index mixin for navigation toggle * Add missing comma in z-index file * Update interface drawer label for navigation sidebar * Recenter document actions * Create variable for header toolbar min width * Use navigation sidebar redux actions and selectors in refactored nav sidebar Navigation sidebar and inserter sidebar state were both moved into the 'core/edit-site' data store. We incorporate any relevant actions and selectors into our source code updates. * Remove unnecessary isNavigationOpened selector * Return isNavigationOpened directly from selector Co-authored-by: Copons <[email protected]>
Seems this did not get backported to WP 5.6 after all. Edit: For reference, this was broken in #26944 |
For context, the max-width was removed in #26944 because not compatible with IE11. It was totally my bad for not testing the change on IE11. I'll open a new issue and try to solve it ASAP. |
Description
Some blocks are somehow able to exceed the editor boundaries and, when set to full width, gain a width of literally millions of pixels, making the editor unusable.
I'm not sure how to justify this solution/workaround, but it works, and it doesn't seem to cause regressions.
See: Automattic/jetpack#17616
How has this been tested?
Tested in both post and site editor, trying a wide array of different blocks, set at wide and full width.
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: