-
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
Fix vertical overflow when inserter is open in post and site editor #57127
Fix vertical overflow when inserter is open in post and site editor #57127
Conversation
Perhaps the following CSS alone can solve the problem? .block-editor-inserter__main-area {
overflow: hidden;
} |
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.
Thanks for looking into this @colorful-tones! This is testing nicely for me so far 👍
Just checking, is it safe to set overflow: hidden
on the interface-interface-skeleton__body
? From memory, hidden
sets a formatting context that can interfere with position: sticky
rules, so it's possible that this could adversely affect things within the editor canvas. In practice, from testing setting a Group block to Sticky in both an iframed and a non-iframe editor, this seems to be working well for me so far 🤔
A couple of other thoughts: do we know what's causing the overflow to be present? Is it possible to contain another area that's unintentionally causing the skeleton body to overflow rather than hiding it with the hidden
rule, or alternately, would it be worth trying overflow: clip
in case we want to avoid the formatting context?
One thing I've noticed is that it can sometimes be quite tricky to make changes to some of these parts of the editor canvas without unintentionally introducing side effects, so it could be good to get a couple more pairs of eyes on whichever approach we'd like to go with here, just in case 🙂
@@ -69,6 +69,12 @@ html.interface-interface-skeleton__html-container { | |||
padding-bottom: $button-size-small + $border-width; | |||
} | |||
} | |||
|
|||
// Prevent unneccessary infinite empty scrolling when empty block canvas |
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's the infinite empty scrolling? In manual testing on trunk
it looks like the editor is scrolling nearly a full height of the editor, rather than infinite. Apologies if I'm missing something here!
Apologies, I didn't see that comment before I submitted my review. That's sounding promising if we can limit the area where we're applying |
I looked into this issue a little more closely. The root cause may be that when you enter a search keyword, there is no element with Default<div class="block-editor-inserter__menu"> <!-- ← overflow:visible; -->
<div class="block-editor-inserter__main-area show-as-tabs">
<div class="block-editor-inserter__search"></div>
<div class="block-editor-inserter__tabs"> <!-- ← overflow:hidden; -->
<div role="tabpanel"> <!-- ← overflow-y: auto; -->
<!-- Block List here... -->
</div>
</div>
</div>
</div> When entering a search keyword<div class="block-editor-inserter__menu"> <!-- ← overflow:visible; -->
<div class="block-editor-inserter__main-area">
<div class="block-editor-inserter__search"></div>
<div class="block-editor-inserter__no-tab-container"> <!-- ← overflow-y: auto; -->
<!-- Block List here... -->
</div>
</div>
</div> There may be several ways to solve this problem with CSS.
Personally, I think the second, simpler approach is better. However, a third approach that matches nested structures regardless of whether a search term is present or not seems good. In other words, there is an element with |
Lots of great feedback. I plan on taking another pass at this today. Thanks! |
That certainly fixes the issue in Chrome. I have yet to do any cross-browser testing, but I certainly will before moving to finalizing any PRs.
I am not clear on this last suggestion. 🤔 Thanks for the guidance @t-hamano |
Sorry for the insufficient explanation. I was wondering if it would be possible to change the hierarchy as shown below when the search text is entered. From: <div class="block-editor-inserter__menu"> <!-- ← overflow:visible; -->
<div class="block-editor-inserter__main-area">
<div class="block-editor-inserter__search"></div>
<div class="block-editor-inserter__no-tab-container"> <!-- ← overflow-y: auto; -->
<!-- Block List here... -->
</div>
</div>
</div> To: <div class="block-editor-inserter__menu"> <!-- ← overflow:visible; -->
<div class="block-editor-inserter__main-area">
<div class="block-editor-inserter__search"></div>
<div class="block-editor-inserter__no-tab-container"> <!-- ← overflow: hidden; -->
<div class="block-editor-inserter__search-results"> <!-- ← overflow-y: auto; -->
<!-- Block List here... -->
</div>
</div>
</div>
</div> However, when I tried this locally, I was unable to resolve the overflow 😅 Therefore, if it can be solved in all browsers, the following approach may be better.
|
Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com>
57f8f51
to
8f9e2cd
Compare
I've used @t-hamano suggested fix and reverted my previous attempts. I also attempted to give co-authored attribution in commit. 🤞 I opted to only target I've tested the fix in both the site editor and the block editor for the following desktop browsers.
I'm attaching videos of all the results. So far it is working nicely. I plan on circling back to do some mobile and tablet testing in iOS simulator, but could use some help with any Android and any other browsers. Thanks! Safari-desktop-17.2-site-editor.mp4Safari-desktop-17.2-block-editor.mp4MS-Edge-120-site-editor.mp4MS-Edge-120-block-editor.mp4firefox-120-site-editor.mp4Firefox-120-block-editor.mp4Chrome-120-site-editor.mp4Chrome-120-block-editor.mp4 |
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.
LGTM ! Thank you for including me as a co-author 😊
I'm using Windows OS, but Chrome, Firefox, and Edge all seem to work fine. However, I would like to ask @andrewserong if this approach is correct 🙇
Tested on iPhone 15 Pro Max (iOS 17.2) and there are no regressions and everything seems to operate smoothly in both the site editor and the block editor. Note: there are a few oddities on Gutenberg 17.2.3 which are featured in the block editor video above, but they're not related to the work for this fix and they're working fine in my branch. So, they've likely been addressed elsewhere. The most noticeable is when clicking 'Add New Post' and landing on the block editor it zooms way in and you just see a giant plus + icon. |
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.
Nice work honing in on a safe fix @colorful-tones and @t-hamano! Using .block-editor-inserter__main-area
feels like a good way to keep the rule contained to me, and makes for a simple fix 👍
✅ Tested in the post and site editors using Safari, Chrome, Edge, and Firefox on a Mac. In each case there were no additional scrollbars, and I found no regressions with any part of the inserter that I could test.
I think we've tested pretty thoroughly in different environments now, so this LGTM! ✨
…57127) * Toggle classname for inserter * Adjust overflow when inserter is open * Revert "Toggle classname for inserter" This reverts commit 95f0a72. * Revert "Adjust overflow when inserter is open" This reverts commit 40fba9e. * Fix vertical overflow for inserter main area Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com> --------- Co-authored-by: Aki Hamano <54422211+t-hamano@users.noreply.github.com>
I'm not sure why, but this issue is caused by the downloadable block lists. Adding this fixes it and the overflow can be removed:
I need overflow to be visible as part of fixing #60209, so I'll probably be pinging y'all about this soon :) Anyone have an idea of why that downloadble-blocks-list would be causing this, and why position relative would fix it? |
I don't know why either, but certainly that style seems to solve the problem with overflow. However, it seems that the problem is not resolved in all cases. For example, if you type "list" in the search box, the problem will be resolved, but if you type "a", the problem will occur. After trying various things, it seems that applying diff --git a/packages/block-editor/src/components/inserter/style.scss b/packages/block-editor/src/components/inserter/style.scss
index ba1107054c..09c35f91c0 100644
--- a/packages/block-editor/src/components/inserter/style.scss
+++ b/packages/block-editor/src/components/inserter/style.scss
@@ -22,7 +22,6 @@ $block-inserter-tabs-height: 44px;
flex-direction: column;
height: 100%;
gap: $grid-unit-20;
- overflow-y: hidden;
&.show-as-tabs {
gap: 0;
@@ -142,6 +141,7 @@ $block-inserter-tabs-height: 44px;
.block-editor-inserter__no-tab-container {
overflow-y: auto;
flex-grow: 1;
+ position: relative;
}
.block-editor-inserter__panel-header { |
What?
Addresses #56811
This needs further cross browser testing, but addresses the initial issue in Chrome desktop.
How?
Adding a class to the
InterfaceSkeleton
component in the site editor and post editor:is-inserter-opened
. Target the class withoverflow: hidden
.Testing Instructions